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 15:37:06 GMT

In article <Pine.WNT.4.10.9908011101240.-381311@lerdorf.raleigh.ibm.com> you wrote:
>> And how do you this way allow a complex module to run their own Autoconf
>> checks outside the source tree, Rasmus? And how do those modules build
>> theirself with libtool? By providing each one their own ltconfig ltmain.sh
>> files? That's not very user friendly to third party authors and full of
>> redundancy. You need a wrapper which provides a module with the _SAME_
>> environment inside and outside, I think. Else we again have to deal with the
>> various differences and this already showed to become nasty. 
> 
> I really don't think it is useful to build something trivial like
> mod_autoindex outside the tree.  Why would anybody do this?  And any
> non-trivial module is likely to already have an autoconf setup.  I
> certainly wouldn't use any Apache-provided wrapper functionality in PHP.
> I am perfectly happy asking apxs to build things correctly.  Same goes for
> mod_perl and mod_dav.  

The point is that IMHO there should be no difference for the module author. He
should always have to setup just one single build enviroment for his module,
independent whether its a complex module or a trivial module. If he starts
with a trivial one and later needs real Autoconf checks he shouldn't be forced
to reinvent his Autoconf approach again.  Instead all he should need is to
write the Autoconf checks itself and place it into a file. But there should be
no change needed to integrate this with Apache. I always hated the fact that
trivial modules can do things easily and complex modules like mod_perl,
mod_ssl, mod_php, etc. have to reinvent the wheel every time.

> But even if we needed this functionality, why couldn't we just do it by
> optionally generating a minimal configure script that sticks in the common
> macros and then adds on the contents of the module-specific config.m4
> script?  

Because a common script can be assembled out of smaller ones only when all
smaller ones are already present. That's not the case for third-party modules.
Apache should make no assumption what a third-party module might need.  It
should provide the environment that the third party module can have access to
all Apache knew at its own built-time and is able to add their own stuff.  All
with the same Autoconf environment.

> This configure.in script would be set up to call apxs and as such
> it would be possible for people to distrbute a mod_autoindex.tar.gz
> tarball that could be untarred and built using: 
> 
>   ./configure --with-apxs; make; make install
> 
> Perhaps this is what you meant by a wrapper.  But to me this is just
> another autoconf-generated bit of magic.

Sure, Autoconf is the major player in this approach. I've never said I want to
reinvent something like Autoconf. What I meant by a wrapper is just a script
which provides the environment so that third party module Autoconf scripts run
fine and have access to Apache's config.cache, Apache's install layout, etc.
pp.
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message