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.
--
Untitled Document
| Bob
Atkins |
| President/CEO |
|
Business Inter-net-working
The Cure for the Common ISP!
|
Phone: (310) 577-9450
Fax: (310) 577-3360
eMail: [EMAIL PROTECTED]
|
|
begin:vcard
fn:Bob Atkins
n:Atkins;Bob
org:DigiLink, Inc.
adr;dom:Suite 408;;4676 Admiralty Way;Marina Del Rey;CA;90292
email;internet:[EMAIL PROTECTED]
title:President/CEO
tel;work:310-577-9450
tel;fax:310-577-3360
url:http://www.DigiLink.Net
version:2.1
end:vcard
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
