[asterisk-dev] zaptel, menuselect and autoconf

Bob Atkins bob at digilink.net
Wed Aug 1 12:20:34 CDT 2007


I do appreciate what menuselect is trying to do but it is completely 
unnecessary with a proper autoconf build process. It makes the asterisk 
build process highly unique and requires reliance on yet another piece 
of software that must be understood and must compile properly 
/_*before*_/ asterisk can be built. It is one more piece of software 
that must be portable across operating systems.

In addition to having the unique aspects of menuselect as part of the 
asterisk build process, autoconf is also used but many of the tests and 
subordinate configure/makes are not implemented properly in that 
necessary compile flags and loader flags along with configure options or 
not flowed down to subordinate configure/make operations which makes the 
build process highly non-portable between different OS and for those of 
us that need to build to custom libraries, without -g, with 
optimization, including certain runtime shared object paths, etc, etc.

I understand that one or more people put time and effort into menuselect 
with the intention of making the build process for asterisk better but 
sadly, menuselect simply re-invents the wheel (autoconf) with a uniquely 
different approach that anyone building asterisk must learn and 
understand. Autoconf has become so widely accepted as the build process 
for virtually all open source software that menuselect really throws a 
serious wrench into the works for those of us that have to maintain and 
deploy a variety of open source packages.

Yes, there are /_*plenty*_/ of build bugs in the v1.4 build process, I 
have only reported a few and I finally got frustrated by the much larger 
number that I was faced with after fixing the v1.2 makefiles. Make no 
mistake - I'm not saying that the v1.2 makefiles were satisfactory 
either. They don't provide any real ability to customize the build. We 
do patch the v1.2 makefiles as well to build it. Asterisk really needs a 
solid autoconf build process to provide the necessary options for 
building on different platforms and directory structures. The question 
is whether to spend the time trying to fix the bugs in the v1.4 build 
process leaving menuselect in place which would just be lots of band 
aids /_or_/ spend the time fixing the bugs and making asterisk v1.4 
completely autoconf compliant. You simply can't have menuselect 
/_*and*_/ an autoconf build process - they conflict with each other. The 
later approach would risk rejection and controversy and the former is 
just a waste of time IMHO and I suspect many others feel the same way. 
The result is stagnation as nobody is making an real effort to fix the 
build problems and contribute those fixes back. We have hammered the 
v1.4 build process into a condition that works strictly for us and I 
suspect others have done similar but due to the ugly and very OS 
specific nature of most of our changes they would not be of any value to 
the community so we have not contributed them back.

Russell Bryant wrote:

>Kristian Kielhofner wrote:
>>  I have had the same issues building with AstLinux.
>>  As has been pointed out before menuselect is not friendly for
>>scripts or Makefiles.  I don't understand why we need it at all.
>>There are already several different ways to build complicated software
>>on *NIX systems.
>Can you please describe what your problems are so that we can fix them?
>Let me go over some things that I have said numerous times already:
>1) You do *NOT* have to run menuselect in interactive mode.  This is
>entirely optional.  Thus, it should not get in the way of automated builds.
>2) It removes *NOTHING* from what we had in Asterisk 1.2.  It only adds
>features to the build system.
>If your problem is that there is an interactive way to customize the
>build, but not an extremely easy way to do it from a script, then that
>is not a problem.  That was never something that was possible.  It *is*
>possible if you generate the proper menuselect.makeopts file, but that's
>aside from the point, really.
>If there is a problem where you are having trouble building Asterisk,
>then it is much more likely related to our configure script and how we
>use its output in the Makefiles.  But, I need some details to fix it.
>Let's identify the real problems here and make sure we're not
>identifying a wishlist item as a serious bug.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20070801/8a862849/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bob.vcf
Type: text/x-vcard
Size: 266 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20070801/8a862849/attachment.vcf 

More information about the asterisk-dev mailing list