httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: Pause to Consider
Date Mon, 29 Nov 1999 20:44:51 GMT
(Rolling through a big pile of Thanksgiving mail...)
On Fri, Nov 26, 1999 at 11:27:36AM -0800, Greg Stein wrote:
> What about all the AC_CHECK_FUNCTION things? How about compiler switches?
> (e.g. symbol definitions) Please don't say every module must supply its
> own set of AC_CHECK_FUNCTION lines(!)
> I can think of several modules that rely on an external DBM-style library.
> How do they share the same configure switch? And don't tell me that I need
> to specify --auth-dbm-uses=GDBM followed by --rewrite-uses=GDBM. Blech.
> Ah! So now you might argue, "well that is common stuff and would go into
> a higher-level Apache configuration." Fine. So you just broke the
> independence of the module :-)

Rasmus spoke for me pretty well. I'll just add that I don't think
completely separate configuration or completely combined configuration
are the answer. That's why the autoconf scripts allow the built-in
modules to get access to common macros in the parent directory to
search for certain things. For example, if you look at how the Unix
MPMs are configured, the Unix threaded MPMs check for pthreads on the
system with a common macro in src/modules/mpm, and all the Unix MPMs
do the same thing for shared memory.

A module is free to use any combination of the common macros kept in
the parent directory and its own. We want support for common
configuration, because there are long ugly checks (like the one for
threads will eventually be), that should be maintained in one place
but are only required by a few modules. With this setup, the mechanism
is there to support any of the flags above that we want.

But, modules that have their own configuration requirements shouldn't
shove their lookups into common scripts, because that makes it harder
for a newbie to figure out what pieces go together. Any special
configuration that a module needs should be bound closely with that

> Rasmus wrote:
> > It would also make it a lot easier for people to replace one of these
> > modules.

> Who cares? I don't think it is a requirement to support replacement like
> this.

Short-term, it's not a requirement. But, over the past few years,
modules have been added and occasionally removed. It would be nice to
reduce the cruft left in the server from potential dead modules.

Manoj Kasichainula -
IBM, Apache Development

View raw message