Re: MetaConfig vs Autoconf (was: Why are we still using trn?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Eric Schnoebelen <> wrote:
: 	However, Autoconf doesn't support the idea of asking the
: _anything_.  *Everything* has to be known in advance, and placed
: on the configuration script command line.

Not really true.  You just have to write the Autoconf macro that will
query the user for values.  The set of macros that comes with Autoconf
doesn't do this of course, because the fundamental idea is that
everything should be detected automatically or configured on the
command line.  That's how Autoconf configure scripts *should* work,
but noone can really stop us from adding interactivity to the configure
script.  I've written hundreds of autoconf macros - even have write-
access to the Autoconf sources (I was active as an Autoconf maintainer
in the 2.13->2.5[012] upgrade process), and making a hybrid, interactive
configure script should be a piece of cake for an experienced
Autoconf/Bourne shell programmer.

I don't want to surprise people by making a configure script be
interactive by default though, but I wouldn't mind having an option
for turning on this kind of thing, and/or letting the configure
script turn on interactivity if it is invoked as Configure instead
of configure (but having files with both names would cause problems
in the case of case-insensitive file systems though, so that might
not be such a good idea).

Nevertheless, most people (just my educated guess) who download and
build sources off the net are most familiar with the Autoconf way - they
may not even have encountered any Metaconf-based packages at all
before they are going to try compiling the newly released trn4-final.
(perl is usually installed by default on all Linux distributions).
To those people, the current system will seem very clunky, and that's
my main argument for reworking the build system.  We need a stream-lined
setup if trn is ever to take over the world ;)

Btw, does Metaconf set up makefiles that can build the package in
separate build directories, so you don't have to clutter up the source
directories with object files and stuff?  That's another thing I can
hardly live without these days...

  Lars J

This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!

[Index of Archives]     [Photo]     [Yosemite]     [Epson Inkjet]     [Mhonarc]     [Nntpcache]

  Powered by Linux