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 17:35:31 GMT

In article <200001211541.IAA28926@sanitas> you wrote:
> In a recent note, Ralf S. Engelschall said:
> 
>> Date: Fri, 21 Jan 2000 16:17:52 +0100
>> 
>> 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
> 
> In the GNU tradition, shadow trees are well supported by "configure".
> _However_ the GNU model is different from APACI; rather than building
> a tree of symlinks to all the sources, it puts only products in the
> shadow trees, and relies on VPATH to access the sources.  VPATH is
> provided by GNU make, and several other vendors' make, but is not
> universal; not even POSIX, AFAIK.

Yes, I know that the GNU way is VPATH. But exactly because it's not
universal and would have required changes to the existing Makefiles
APACI's variant was born. And I think even for Apache 2.0
the situation will be not much different ;)

>> 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)
> 
> I believe I have this clear: to you, "backend" is the author side;
> "frontend" is the consumer side.

With frontend I mean the "configure" script itself and the options it
provides to the end user for building the stuff. With backend I mean all
shell/perl/whatever code which is called from this "configure" script.
Still for the end user, of course. What you're talking about is the
"does the consumer reaqure Autoconf" issue, right? This has nothing
do to with my stuff I talk about. The backend, even if generated by
Autoconf, should not require Autoconf for the end-user/consumer side,
of course. All I say is that the script is _generated_ by Autoconf. For
the consumer there should be always just those tools required which are
absoluetely necessary (like /bin/sh, etc.). That's clear. But what I
talk about is that if one moves Autoconf scripts to the backend of the
config system and can make it optional and this way non-Unix platforms
can easily provide alternatives. Is it now more clear what point I want
to address?
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message