httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <>
Subject Configuration & third path modules
Date Sun, 08 Mar 1998 13:11:12 GMT
Hi. I've only just caught up with the whole of this thread about
configuring Apache and modules. The idea of the .module stuff was to make
it easier for third party modules. I think that has happened to some
degree, but there is still more to do to support major modules. 

When I added the .module stuff and auto-Makefile creations, I thought that
modules would be built during the Apache's Make phase. Modules would make
use of os.h to obtain the compile-time information that they need. All the
modules distributed with Apache and many third-party ones work like this.

However there is a class of major modules which like to be built
separately from Apache, then link in via a small connecting module. php
and jserv are like this (and mod_perl, although its linking module isn't
really that small).

The ap_config.h file may help with configuration, but still leaves a
circular problem with library references. Consider a module which has a
.module file which adds a library to EXTRA_LIBS (like mod_auth_db.c adds
-ldb). Say it does "LIBS=$LIBS -lmymodule". If an AddModule line added
pointing to this .module file, running ./Configure will _fail_ because
-lmymodule does not yet exist. But the module and library _cannot_ be
built until after ./Configure has been run!

The problem is really with the "TestCompile sanity" part of Configure. 
This requires that all configured-in libraries exist, before anything has
actually been built. I would like to see this check removed, or at least
made optional, defaulting to off. This would make adding third-party
modules much easier. Or if the sanity check is needed, we need to
distinguish between libraries that are built as part of the build process,
and system libraries needed to compile. For example, add a new variable
$MY_LIBS or similar, which is not tested in the sanity check. 

A second problem for major modules is SERVER_SUBVERSION. They like to add
themselves to this by doing


which is fine, except when two or more modules decide to do this you get
warnings about redefined macros and only one module gets added to the
version. I think we should add a variable for use as the subserver version

  $SUBVERSION="$SUBVERSION mymodule/123"

to give all modules and equal chance of getting onto the version line. 

View raw message