Given a scenario where a module has a dependency on both
an external library and a module if the external library was
available and the module was not an infinite loop would
occur. This happened due to the code changing the dependecy
status to no failure on each dependency checking loop
iteration, resulting in the code thinking that it had
gone from no failure to failure each time triggering another
dependency check.
This change makes it so that the old dependency status is
preserved throughout the dependency checking allowing it to
determine that after the first iteration the dependency
status does not transition from no failure to failure.
ASTERISK-28930
Change-Id: Iea06d45d9fd6d8bfd068882a0bb7e23a53ec3e84
The Binaural Rendering patches in the master branch required
menuselect to be updated with a new support type called 'option'.
This allows binaural rendering to be turned on or off when
bridge_softmix is built. This patch backports the 'option'
functionality to the 13 and 14 branches.
Here's what it looks like in menuselect:
[*] bridge_simple
[*] bridge_softmix
--- Module Options ---
[ ] binaural_rendering_in_bridge_softmix
To create an option for a module, you can create (or update) the
menuselect-tree xml snippet in the directory where the module
resides and add a member element with an 'option' support_level.
Example (abbreviated) from bridges/bridges.xml:
<member name="binaural_rendering_in_bridge_softmix"
displayname="Enable binaural rendering in bridge_softmix"
remove_on_change="bridges/bridge_softmix.o bridges/bridge_softmix.so">
<support_level>option</support_level>
<depend>bridge_softmix</depend>
<depend>fftw3</depend>
<defaultenabled>no</defaultenabled>
</member>
The 'name' will be added or removed from the MENUSELECT_<dir>
make variable following the standard module "missing means yes"
rules.
Example (abbreviated) from bridges/Makefile:
ifeq ($(findstring binaural_rendering,$(MENUSELECT_BRIDGES)),)
bridge_softmix.o: _ASTCFLAGS+=-DBINAURAL_RENDERING
bridge_softmix.so: LIBS+=$(FFTW3_LIB)
endif
Change-Id: I66d23755ed6e81f8d439cad410f2ffa7c30f25ad
The strdupa function is a GNU extension, and not widely portable. We
have an ast_strdupa function used within Asterisk which is preferred.
I pulled the definition up from menuselect.c into the menuselect.h
header file so it can be shared across menuselect.
Change-Id: I9593c97f78386b47dc1e83201e80cb2f62b36c2e
* Add 'external' as a support level.
* Add ability for module directories to add entries to the menu
by adding members to the <module_prefix>/<module_prefix>.xml file.
* Expand the description field to 3 lines in the ncurses implementation.
* Allow the description field to wrap in the newt implementation.
* Add description field to the gtk implementation.
Change-Id: I7f9600a1984a42ce0696db574c1051bc9ad7c808
(cherry picked from commit 90f445729d)
I can't ever recall actually needing the intermediate files or the checking
that a double compile produces. What I CAN remember is every DONT_OPTIMIZE
build needing 3 invocations of gcc instead of 1 just to do the checks and
produce those intermediate files.
Having said that, Richard pointed out that the reason for the double compile
was that there were cases in the past where a submitted patch failed to compile
because the submitter never tried it with the optimizations turned on.
To get the best of both worlds, COMPILE_DOUBLE has been split into its own
option. If DONT_OPTIMIZE is turned on, COMPILE_DOUBLE will also be selected
BUT you can then turn it off if all you need are the debugging symbols. This
way you have to make an informed decision about disabling COMPILE_DOUBLE.
To allow COMPILE_DOUBLE to be both auto-selected and turned off, a new feature
was added to menuselect. The <use> element can now contain an "autoselect"
attribute which will turn the used member on but not create a hard dependency.
The cflags.xml implementation for COMPILE_DOUBLE looks like this...
<member name="DONT_OPTIMIZE" displayname="Disable Optimizations ...">
<use autoselect="yes">COMPILE_DOUBLE</use>
<support_level>core</support_level>
</member>
<member name="COMPILE_DOUBLE" displayname="Pre-compile with ...>
<depend>DONT_OPTIMIZE</depend>
<support_level>core</support_level>
</member>
When DONT_OPTIMIZE is turned on, COMPILE_DOUBLE is turned on because
of the use.
When DONT_OPTIMIZE is turned off, COMPILE_DOUBLE is turned off because
of the depend.
When COMPILE_DOUBLE is turned on, DONT_OPTIMIZE is turned on because
of the depend.
When COMPILE_DOUBLE is turned off, DONT_OPTIMIZE is left as is because
it only uses COMPILE_DOUBLE, it doesn't depend on it.
I also made a few tweaks to the ncurses implementation to move things
left a bit to allow longer descriptions.
Change-Id: Id49ca930ac4b5ec4fc2d8141979ad888da7b1611
This is the final patch in adding menuselect to Asterisk.
- The first patch (r418832) added menuselect along with mxml
- The second patch (r418833) removed mxml from menuselect
This patch adds support for libxml2 to menuselect, and makes libxml2 a
required library for Asterisk.
Note that the libxml2 portion of this patch was written by Sean Bright,
and was made available on a team branch:
http://svn.digium.com/svn/menuselect/team/seanbright/libxml2/
Review: https://reviewboard.asterisk.org/r/3773/
ASTERISK-20703 #close
patches:
some_mysterious_team_branch uploaded by seanbright (License 5060)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the first patch that adds menuselect to Asterisk trunk, and removes
the svn:externals property. This is being done for two reasons:
(1) The removal of external repositories eases a future migration to git
(2) Asterisk is now the only thing that uses menuselect; as a result, there's
little need to keep it in an external repository
Subsequent patches will remove the mxml dependency from menuselect and tidy
up the build system.
ASTERISK-20703
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418832 65c4cc65-6c06-0410-ace0-fbb531ad65f3
