Summary:	ASTERISK-05883: [branch] asterisk/team/group/autoconf_and_menuselect
Reporter:	Russell Bryant (russell)	Labels:
Date Opened:	2005-12-21 20:22:13.000-0600	Date Closed:	2006-02-27 08:04:57.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Generating the configure script: $ cd /usr/src/asterisk $ cd autoconf ... Read the README on how to generate the configure script ... Run configure: $ ./configure Run menuselect: $ cd .. $ make menuselect Here is an overview of the current functionality of menuselect: 1) menuselect reads all of the makeopts input files to build a tree of all of the available options, including information about their external dependencies 2) menuselect uses the menuselect-deps file generated by configure to determine whether dependencies are met.  If dependencies for a module are not satisfied, then menuselect will not allow the user to select it. 3) When the user saves changes in menuselect, an asterisk.makeopts file is generated. 4) asterisk.makeopts is included by the main Makefile.  This file simply includes the variables that say which modules to build. ****** ADDITIONAL INFORMATION ****** The code related to this is currently being maintained in a branch off of the asterisk trunk.  It can be checked out with the following command: $ svn co http://svn.digium.com/svn/asterisk/team/group/autoconf_and_menuselect To view all differences between my branch and the trunk, use this command: $ svn diff http://svn.digium.com/svn/asterisk/trunk http://svn.digium.com/svn/asterisk/team/group/autoconf_and_menuselect
Comments:	By: Tzafrir Cohen (tzafrir) 2005-12-22 01:40:59.000-0600 A couple of notes: XML is probably not fun to work with. It is not easy to manually edit. It does not lend itself to simple inclusions. It can easily break badly with a diff. If you want to keep up with the current makefiles, you better keep one file per directory. Otherwise that specific file will be the common point to many patches and thus a source of maintinance headache. What about non-interactive builds? 'make oldconfig' 'make all-yes' ? Also: maybe aim higher and borrow the whole of kbuild from Linux 2.6? By: Russell Bryant (russell) 2005-12-22 01:54:38.000-0600 1) I found it extremely easy to parse the xml file.  I got the library installed and was parsing the file in easily less than an hour.  I'm not sure what you mean about it breaking with a diff.  It's just like any other text file.  I am of course open minded to suggestions of other ways to store this information.  However, I think that this information could be useful to applications outside of menuconfig, so using a common format such as XML is beneficial. 2) That is an interesting point.  However, I'll have to think about the easiest way to make that happen. 3) The menuconfig application will automatically ignore settings in an existing makeopts file that are no longer supported (not defined in the input makeopts.xml file). 4) I chose not to try to use something that already existed for a couple of reasons.  Honestly, the biggest reason I wrote something from scratch is that it was fun to do.  Also, this gave me the luxury of writing it in a way that would not be very intrusive to our current build system. By: Tzafrir Cohen (tzafrir) 2005-12-22 03:05:04.000-0600 Regarding XML not being human-editable: see, for instance: http://yaml.org/ http://yaml.org/start.html As you can see, such a file is much simpler to hand-edit. You can also manipulate it with simpler line-oriented tools such as sed and grep (show me an xmlgrep that is installed in every distro and that 10% of the people who build Asterisk know how to use). By: Russell Bryant (russell) 2005-12-22 08:37:34.000-0600 Well, that one specifically is not going to be of much help, since I do not see a C library. By: Russell Bryant (russell) 2005-12-22 12:57:19.000-0600 I have updated the branch to split up the makeopts.xml file into multiple files - one in each sub directory. By: Telecom & Internet Integrated Solutions (teleweb) 2005-12-22 18:01:12.000-0600 I agree that XML is definitely the right choice and very easy to work with! I would in fact like to see a movement towards XML *everywhere* in Asterisk! XML is a universal language for config files, unlike the current format used by Asterisk... It would make things uniform and life so much easier!  Moreover, XML is the same on every platform, and parsers and API's exist for every platform. Are there plans in that direction already? (I hope so!) By: BJ Weschke (bweschke) 2005-12-22 23:45:13.000-0600 teleweb: there's a general consensus that "XML is OK" for stuff that isn't used in the direct operational functions of Asterisk. However, I believe it's still frowned upon for use in the operational functions when that can be helped. By: Tzafrir Cohen (tzafrir) 2005-12-23 05:14:18.000-0600 XML is nice for config files, as long as you don't need to modify them yourself. It is simply too easy to leave out a tag and thus lose or move a complete branch. XML excels at serailzing complex data structures (mainly trees). But when you need to manipulate that XML too much, you'll notice you don't have the rich toolset you have for simpler files. For example: how would you implement #include and #exec in a robust manner? By: Russell Bryant (russell) 2005-12-23 11:17:38.000-0600 I'm not sure why you think these files are going to be edited so much.  They would almost never be modified.  The only time they have to be modified is when a new module gets added.  Your argument about it not being easy to modify by hand is really going nowhere. It would be fairly easy to add a feature into the application to allow input about information for a new module, and have the application re-write the XML file.  This is all supported in the library that I am using.  (Thanks to twisted for this idea!) You say that XML excels in storing tree information.  Well, that is exactly what we have here. Patches are welcome for alternate solutions. By: Russell Bryant (russell) 2005-12-24 03:23:55.000-0600 As an update on the plan of attack here, we plan on using a combination of autoconf as well as this menu application for configuring the Asterisk build process.  To quote kpfleming on his idea of how this will work, which I very much agree with ... "Here is what I would like to see: a _combination_ of a 'configure' script and a 'menuselect' (renamed from 'menuconfig'), that the user would execute in order. The 'configure' script would do the normal autoconf-type stuff; find libraries/headers, create a config.h file, set up things to use the right compiler/linker and external tools, etc. The 'menuselect' process would then let the user select which modules they wish to build, with only the ones that are actually buildable available for selection (for example, if no unixODBC libraries/headers are found or are usable, then the ODBC-using modules would be 'grayed out' in menuselect). This allows for the best of both worlds: the user can preserve the output of 'menuselect' for re-use in multiple installations, but still run 'configure' for each build to make the build work properly with their compiler/libraries/etc." By: Russell Bryant (russell) 2006-01-22 18:47:17.000-0600 suspending pending more progress in autoconf integration ... By: Russell Bryant (russell) 2006-01-30 13:47:07.000-0600 This is now ready for further feedback and testing.