httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: Apache 2000, err Apache 2.0 gets real
Date Sun, 01 Aug 1999 14:42:25 GMT

In article <Pine.WNT.4.10.9908011005200.-381311@lerdorf.raleigh.ibm.com> you wrote:

>> That's why I appreciate that we don't try a quick "translate all to Autoconf"
>> for Apache 2.0.  Instead especially for the module config and build process
>> and DSO situations we should create a well-considered environment.  And I'm
>> convinced Autoconf is not all we need here. I'm even convinced that the
>> "configure" script(s) should be not directly the ones generated by Autoconf!
>> Instead the Autoconf scripts should be run in a special environment in the
>> background of our own "configure" scripts.  But ok, it's too early for those
>> details...
> 
> This sounds overly complicated to me.  

Yes, it's complicated to design, but it should be not complicated to maintain
or use later. The wrapper scripts are mainly trivial ones, I think.

> One of the nice things about a
> straight autoconf setup is that when you realize you are missing a test
> for something, chances are someone out there has already written it.  It
> should not be made unneccesarily complex for people to tweak the autoconf
> stuff and contribute the changes back.  The current
> ./configure-src/Configure-src/support/apxs.pl-apxs-make install chain
> effectively produces 4-levels of indirection and is nearly impossible to
> grok unless you are really stubborn and determined to figure it out.
>  
> Obviously an automake/autoconf setup has many levels as well, but at least
> it is a known sequence.  People familiar with the environment can dive
> right in and be productive right away.  I would really like to avoid
> adding extrananeous levels here.  Like you asked Jim, can you give an
> example of something that can't be done within the normal confines of an
> autoconf/automake setup that would require this additional step?

Sure, look at this: For the DSO situation we currently use a different
approach for building inside and outside the source tree. Ideally each Apache
2.0 module should be able to build under both environments and there should be
no difference for the author and end user. But both environments are
different.  With a plain Autoconf configure script we get into trouble.  There
you need a little bit of wrapper code (not more than a few KB of shell script)
which for instance knows paths, knows how to load a global config.cache, etc.
can provide a reasonable user interface here which shadows the environment
differences _BOTH_ to the end user _AND_ to the Autoconf scripts in the
background.
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message