httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rasmus Lerdorf <>
Subject Re: Pause to Consider
Date Fri, 26 Nov 1999 12:03:03 GMT
> 1. A module in its minimalistic form is a directory with three files:
>    foo/
>    foo/
>    foo/mod_foo.c
> 2. There is a general Apache build program (lets say it's 
>    still named apxs) which is available to modules both inside the source tree
>    (there apxs is uninstalled and its answers to queries result in local paths
>    like -I../.., etc.) and outside the source tree (there apxs is installed
>    and answers the queries with install paths like -I$prefix/include, etc.).
> 3. The module _author_ (not the end user!) runs
>    $ cd foo
>    $ apxs prepare
>    This creates a configure script out of with the help of
>    Autoconf's, Automake's and Apache's *.m4 files on-the-fly and creates a
> via Automake and some Apache templates.
> 4. If foo should be built inside the source tree, it's placed
>    into, say, src/modules/foo/. Nothing else is adjusted. The user runs
>    Apache's top-level "configure" script and just says he wants foo with
>    --enable-module=foo. This configure script then created etc/apxs and for
>    each module it does mainly the following: (cd src/modules/$name &&
>    ./configure --cache-file=../../config.cache --with-apxs=../../etc/apxs) and
>    it adds "foo" to the subdir movement support for src/modules/.  Then under
>    "make" it steps down to this src/modules/foo/ and builds either a mod_foo.a
>    or a Similar for "make install". 
> 5. If foo should be built outisde the source tree, it's just extracted
>    from its tarball. Then the end user runs `./configure' (or even
>    `./configure --with-apxs=/path/to/apache/bin/apxs' and this internally
>    (through APXS's information) is immediately transformed into `./configure
>    --cache-file=/path/to/apache/etc/config.cache --prefix=/path/to/apache
>    ...'.  Then the build process is _EXACTLY_ the same as for the internal
>    stuff.  The differences are just that -I../.. then is
>    -I/path/to/apache/include, etc.
> Do you know see what particular approach I have in mind?  If yes, you see why
> _any_ links (ranging from a "cat *.m4" to other things) are not allowed
> between the core and modules.
> And how do you integrate such a module into a larger package? Either you add
> the larger packages stuff to the modules (can be acceptable for
> not too large packages) _OR_ you just place the foo/ stuff into a subdir of
> the larger package (as it would be certainly the case for PHP, etc.) and just
> use AC_CONFIG_SUBDIR to link it into the package.

The main problem with an approach like this, even if we are using a shared
config cache, is that running configure once for each module takes a long
long time.  Being able to run configure once for a group of modules by
doing a 'cat *.m4' of the bundled modules is a very nice shortcut.  I
don't see any explicit limitation in that approach that stops us from
doing something similar to what you have in mind.  libapr, for example,
currently has its own configure script.  It isn't called from the
top-level configure yet, but that's just because Manoj hasn't done that
yet.  And if you look at the PHP 4 build mechanism which Manoj's stuff is
modelled after, you will see that the libzend and TSRM directories contain
their own configure scripts and are not part of the 'cat *.m4' process.

For things that need to be built externally for some reason it makes sense
to give them their own configure script.  But why in the world would
mod_env, mod_imap (I really really hate that name), or mod_userdir need to
be compiled as external modules?  I just don't see it.  

For large external modules like mod_php and mod_perl it makes sense to me
to have them build externally and simply copy configure and Makefile
scripts into the Apache source tree when they need to be built as static
Apache modules.  If we can do something so that apxs can help an external
module generate these files correctly, great.


View raw message