httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: Working on autoconfing Apache 2.0
Date Fri, 19 Nov 1999 07:57:52 GMT
On Thu, Nov 18, 1999 at 11:10:42AM +0100, Ralf S. Engelschall wrote:
> [I know that I'm boring with my cleanness advices, but...]

I'm very pro-cleanliness. This is all very messy business, though...

> My only suggestions is that it would be very nice if the particular approach
> is first written down in a little text file which we can use to discuss
> various issues. The whole Autoconf stuff for Apache 2.0 is _HORRIBLY_ complex
> if you want to cover mostly the same features than the old scripts (at least
> that is what I concluded after thinking about it a few times). So it is
> wise to first write down what should be kicked out, what should be still
> provided and then especially _HOW_ this should be provided within
> Autoconf.

OK, here is a long more detailed version of what my plan (or non-plan,
as the case may be) has been lately.

We're going all the way. autoconf, automake, and libtool.

Make the configuration system modular, so that if we want to redo
certain sections, the others don't get affected too badly. This means
that each directory has its own m4 script which is responsible for
configuring the things in that directory. I've stolen (and probably
will change) a shell script from PHP which merges these M4 files for
automake's consumption, and I'll do the same for the

This way, we get as little dependence between the various parts of
Apache as possible. Also, modules like mod_rewrite can have their own
m4 scripts to add their own config checks. Then, those checks won't be
included when mod_rewrite isn't compiled in.

My hope is that by making the system modular, it allows a more
gradual transition from the old directory layout to a new one, rather
than having to do it all at once. Then, for example, src/modules can
be rearranged without destroying the config scripts for the rest of
the server.

I'm also not working too hard on writing the m4 code for directory
hierarchies that I think will be changing radically, like
src/modules/standard. In that case, the config.m4 just includes a
fixed set of modules. Once each module gets its own directory, then we
can write the more useful M4 code for command-line selection of
modules, and hopefully, the rest of the server config scripts won't be

For me, a gradual methodology is more approachable, because I am an
autoconf newbie, and it also means that we can work in the current CVS
repository, meaning more people can try it out and improve it.

Now more specifics on what I think the config scripts should look like

- Whenever possible, the existing mechanisms of autoconf/automake will
  be used. So, CFLAGS is the exclusive means of setting optimization
  flags. Added debugging flags are set using the preprovided
  --enable-maintainer-mode. And so on.

- An MPM gets selected with --use-mpm=MPMNAME. The other rules will
  probably be replaced with --enable-RULENAME flags rather than
  --enable-rule=RULE, because that's the convention that autoconf

- The selecting of the other modules would be done using
  --enable-MODULENAME[=static,shared]. I'm also pondering some sort of
  --enable-module=MODULENAME structure, but that doesn't seem to
  follow autoconf conventions.

- suexec would be done with --enable-suexec[=suexecpath]. Other
  arguments would be made available to configure suexec details.

- The rest of the options will look similar to APACI. Some --with
  statements would become --enable, because the autoconf info
  documentation implies that --enable should be used for internal
  configuration, and --with should be used for dealing with external
  packages. I don't know if it really matters.

> For instance, it took me already months to make the Autoconf stuff of a small
> project like GNU Pth very clean and maintainable. So you can expect even more
> for Apache 2.0. And it will work only in the long-term only if it's done
> cleanly from the first step. So I personally would appreciate not to kick
> in something existing.

So far, this is all done from scratch, with guidance and snippets of
code taken in when they are known to be appropriate.

> Especially do a little bit more evaluation than just looking at one
> project. There are more good Autoconf usages out there. Grab the
> best of each project.

I'm looking at other projects as well. PHP is just the major template.
One reason is that they have dealt with a lot of the same problems
that Apache needs to handle, such as selecting from a long list of
modules, and allowing them to be DSOs or compiled in.

I'm open to comments about any of the methodology above. As soon as I
can get Apache to compile with these scripts, I plan to commit or
release them, and I'll do so sooner if anyone's interested in playing
with them.

Manoj Kasichainula - manojk at io dot com -
"Violence is the first refuge of the violent." - Aaron Allston

View raw message