[asterisk-dev] zaptel, menuselect and autoconf

[Tzafrir Cohen]

On Tue, Jul 31, 2007 at 10:46:15AM -0500, Tilghman Lesher wrote:
> On Tuesday 31 July 2007 08:13, 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.
> 
> Not in your command-line history, but your choices are saved and will
> persist across an upgrade (assuming you're still in the same release
> branch).
> 
> > 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)?
> 
> Please understand the difference between automation and persistance.  I
> simply meant that you only need to interact with menuselect once, at the
> point of installation.  Thereafter, you need only run the sequence.
> Furthermore, the sequence that you run to upgrade your entire install
> base is the same, regardless of the difference in cards installed in
> each machine.
> 
> I do understand that as a package maintainer, your needs are different,
> in that you would prefer to have automation over persistence, but for
> those of us who install Asterisk from source, the persistence is
> preferred.

If you didn't change anything, why run configure?

If you just want to regenerate all of the config files created by
./configure without needing to remember the command-line parameters you
used, run:

  ./config.status

You can always have ./myconfigure with all of your switches and
enviornment settings for configure. This will also help cross-builders.

Would it help if I add to configure.ac an extra --with switch to
generate a ./myconfigure script with all the command-line options
(except the --with, of course) ?

Or is this too much of a bloat?


And my original question still stands: why is a custom configuration 
actually needed? Besides being cool, how useful is it? 

Again: use cases, please.

-- 
               Tzafrir Cohen       
icq#16849755                    jabber:tzafrir at jabber.org
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir