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