[asterisk-dev] zaptel, menuselect and autoconf

[Tilghman Lesher]

On Tuesday 31 July 2007 11:20, Tzafrir Cohen wrote:
> 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?

Because sometimes the developers change what is autodetected, even
during a release, because a distribution changes what is required.

> 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

That would work, assuming the base configure script didn't change.

> 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?

I don't see the necessity of it, over what we have now.

> And my original question still stands: why is a custom configuration
> actually needed? Besides being cool, how useful is it?
>
> Again: use cases, please.

I already provided one such use case above.  Why is your way better?
Use cases, please (since you insist upon them).

-- 
Tilghman