httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: Pause to Consider
Date Fri, 26 Nov 1999 10:58:47 GMT

In article <Pine.WNT.4.21.9911251600000.-474279@lithium.jetpen.com> you wrote:
>> > Well, we have actually thought about it.  I don't quite understand why you
>> > think the "cat *.m4" stuff would break apxs in any way.  
>> 
>> Because what do you want do with *.m4 files outside the source tree? The
>> end user doesn't have any development tools like Autoconf, Automake,
>> m4, etc. installed. So you cannot even bootstrap and create a local
>> configure script there. For this reason it's important that modules are
>> really stand-alone. And one implication is that you can't just merge
>> *.m4 files into a global configure.in.
> 
> Right, but this has nothing to do with apxs as apxs is used today. 

Sorry if I was not clear enough. I don't mean that it breaks APXS as it is
today. I more meant that it breaks the external building in general (whether
provided by APXS or some other facility is not important for me), because such
"cat *.m4" and other links smooth the borders between the core part and the
module, so the module no longer can be easily (i.e. without any hacks or
adjustments) being configured and built both inside and outside the source
tree.

> apxs
> is a DSO-building tool and when we are building an external module as a
> DSO there is no need to do anything.  All we need is something that will
> tell the external module how to build and where to install stuff.
> 
> I do understand your concern regarding statically linked external
> modules.  I don't see how this can be done cleanly.  The current
> implementation is a hack job.  Such a hack job can be done again.  Short
> of mimicing autoconf/automake in some mammoth homegrown configure
> mechanism how would you do it?  

And these "hack jobs" I would appreciate to completely avoid.
My concrete idea and wish is this:

1. A module in its minimalistic form is a directory with three files:
   foo/configure.in
   foo/Makefile.am
   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 configure.in with the help of
   Autoconf's, Automake's and Apache's *.m4 files on-the-fly and creates a
   Makefile.in 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 mod_foo.so. 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 configure.in (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.

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message