[asterisk-dev] zaptel, menuselect and autoconf

[Bob Atkins]

The issues you bring up with menuselect in terms of automating the build 
process is why we ripped it out completely from the v1.4 build process. 
We just replace the Makefile with our own which is actually a derivative 
of the v1.2 Makefile that we corrected quite some time ago to support 
building properly on Solaris systems but the corrections were never 
accepted when we submitted them.

A 'standard' autoconf build process would make life for everyone much 
simpler however, we found that autoconf was not implemented in a 
portable manner in v1.4 either - important compile options were not 
being passed down to subordinate builds so everything would break during 
the build process. We also reported this problem in another bug report 
with suggested fixes but that report also died quietly as well.

Basically, we just end up doing our own thing.


Tzafrir Cohen wrote:

>On Tue, Jul 31, 2007 at 07:34:54AM -0500, Tilghman Lesher wrote:
>  
>
>>On Tuesday 31 July 2007, Tzafrir Cohen wrote:
>>    
>>
>>>>Asterisk is really the application menuselect was designed for. However,
>>>>is there really a point for the common user to disable building modules?
>>>>Again: "make the common task simple, make everything possible". One
>>>>problem with menuselect of today is that it makes it all too easy to
>>>>accidentally building a module.
>>>>        
>>>>
>>>So again: what usage scenarios are there where there is a benefit from
>>>using menuselect with asterisk?
>>>
>>>(This is not a rhethorical question. Please provide examples)
>>>      
>>>
>>I think the main benefit is persistance.  If you really only need to build
>>two modules for a particular installation, then it is easier simply to
>>do (on update):  "svn update ; ./configure ; make ; make install" (and
>>remember, it is EXACTLY the same sequence as Asterisk, which, on
>>an update, you are going to build as well).  And the persistance saves
>>you both thought time (what does this box actually have installed in it?)
>>and compile time (why am I compiling a module that this box will never
>>use?).
>>    
>>
>
>Is this supposed to be quoted as an atvantage of menuselect?
>
>Menuselect breaks persistance: it starts a user interface. It
>must be interactive. Thus does not allow simple automation the way
>configure (autoconf) is. You can't "save" the choices you made there in
>your command-line history.
>
>How do you automate the action of "disabling chan_zap"? How do you
>automate the action of "enabling only ztdummy" (of the zaptel kernel
>modules)?
>
>The first is supposed to be rather easy, but in fact not
>well-documented, and took me quite some time to understand (and with
>non-intuitive variable names). The second is practically impossible.
>
>  
>

-- 
*Bob Atkins * 
/President/CEO/

*DigiLink, Inc. <http://www.digilink.net>*
Business Inter-net-working
*/The Cure for the Common ISP!/*

	

Phone: (310) 577-9450
Fax: (310) 577-3360
eMail: bob at digilink.net

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20070731/c248a5f3/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DigiLink_esig_logo.jpg
Type: image/jpeg
Size: 23605 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20070731/c248a5f3/attachment-0001.jpg 
-------------- 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/20070731/c248a5f3/attachment-0001.vcf