httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: How to build 2.0 with autoconf
Date Fri, 21 Jan 2000 15:17:52 GMT

In article <Pine.LNX.4.10.10001201608200.12914-100000@shell.ntrnet.net> you wrote:
 
> I am responding to all three recent messages in this thread here.  All
> three are about porting the autoconf build process to non-unix platforms.
> 
> 1)  This is convincing me even more that autoconf is a bad thing.  :-)
> [...]

I see the smilay, but that's why I tried (unsuccessfully) to convince
us a few weeks ago, to first think about the _WHOLE_ config and build
environment before starting coding on it and also why I said that
Autoconf certainly should be used as a _BACKEND_ tool in the config
environment of Apache. Sorry, but IMHO it's not Autoconf's fault if it now gets
complicated for Apache 2.0 to build on non-Unix platforms, it's more or
less just a simple consequence of using Autoconf directly as the config
frontend. Autoconf was definitely not designed for non-Unix platforms,
so either one doesn't care about non-Unix platforms (as I personally
usually do) or one has to use Autoconf as an _optional_ backend, i.e. on
Unix it provides the config parameters, while on non-Unix some other
portable mechanism does.

Once ago for those who now want to listen: For Apache (where non-Unix
and some non-standard Autoconf features like shadow trees, etc. have
to be supported), Autoconf can be a great benefit, but should be used
as a backend while as the config frontend something similar to the old
APACI is required. This frontend then uses Autoconf under Unix, static
files under totally brain-dead platforms and perhaps even Perl (or
whatever else is known to be 100% available on a particular platforms)
on other platforms to determine the config parameters. BTW, this way the
"Autoconf defines are not surrounded with #ifndef ..#endif discussion"
is also solved.

BUT: Such an approach requires a very _CAREFUL_ design of such a
frontend and not again a "lets rock" approach. I know that this is very
boring for some of us, but think about the current situation: Every week
a new problems occurs (the "#ifndef #endif" thing, then Automake makes
problem and let us not use it, etc.). So, is the current approach a I
still convinced that the approach described above would be still worth
to be considered...
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message