[asterisk-dev] zaptel, menuselect and autoconf
Bob Atkins
bob at digilink.net
Wed Aug 1 12:20:34 CDT 2007
Russell,
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