httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Build process requirements
Date Tue, 25 Apr 2000 09:18:26 GMT
OK, my thoughts on what we should support or not support in the build
process. I'm very wishy-washy on all these points, and I've purposely
taken a naive perspective on what worked and didn't work in the past
to be able to think somewhat clearly. Now is the time to bang on the
design with pragaticism, and scream about details that weren't

Executive summary

Simple is good. Support as little flexibility as possible while
allowing users to do what they want.

We will support DSOs and compiled-in modules for all platforms with
these caveats:

 - Modules that require core configuration decisions must be
   compiled non-DSO and are only supported for non-developers if
   distributed by us.
 - Modules that don't require core configuration decisions can be
   compiled either as DSOs or not. But an Apache httpd must either
   have all such modules compiled as non-DSO (meaning no apxs
   support), or all as DSOs.

Note that there's no distinction made for 3rd-party modules.

We do this with autoconf, a make system that is semantically a single
top-level makefile for everything except libraries (APR, PCRE) and
DSOs. All DSOs are compiled using apxs.

The convuluted thought process that got me here

We have to have support for building third-party modules.  We want
every module to be buildable during the Apache build process or
afterwards with an apxs tool. 

Now, do we want to require that every module be buildable both ways?
If so, one conclusion I could come to is that we should just use an
apxs tool to build all our modules, and thus simplify a lot.

Now, one problem is that MPMs are modules too, and they necessitate
changes in the Apache core. The two possible answers to this are to
either make a special exception for MPMs, or allow for a special class
of modules that need to change how the core is built.

I prefer the latter, so we now have two types of modules:

"good": Modules that don't affect the building of the core in any way
"evil": Modules that do

I lean towards the opinion that "evil" modules must be compiled
into the server. It just feels wrong to have modules that result in
changes to the core being kept independantly from the core. And, since
MPMs are evil, this jives with our current worldview anyway.

For "good" modules, I don't see a lot of utility in selecting lists of
modules that can be compiled into the server while others are DSOs.
Let's just have a single --disable-dso flag that makes all our good
modules compiled into the server. A DSO-disabled server won't be able
to load third-party modules, but I see such a beast built mainly for
benchmarking, development, and platforms that don't support DSOs, so
this isn't a problem.

Now, I don't have any intense objection to giving users the
flexibility of selecting only some modules to be built into the core
server.  But, I just don't see the point. By eliminating the practice,
we make our users somewhat less confused, and simplify the build
engine. And if there's one thing this group can agree on, it's that a
simple build engine is good.

Now, how exactly should the modules be built? Here are the features
that any module (ours or 3rd-party) needs based on what I wrote above:

A. per-module configuration that affects the core (evil-only).
B. per-module configuration that doesn't affect the core.
C. Retrieving any configuration that Apache provides.
D. Compiling
E. Linking into the server
F. DSOs (good-only)

So, what do we need to support each of these features if we use

A. I guess this depends on whether we want 3rd-parties to be able to
provide evil modules. If not, we can get away with what we have now: a
config.m4 that gets sourced by Do we have to support
third-party MPMs for non-developers? I think it will be kind of
painful to do so.

B. This kind of thing can be kept local to a module. We now have the
choice of sourcing a config.m4 and making that module's config part of
the global config, or executing a module's configure script (with or
without using our config.cache). Now, we have to support the latter to
support apxs-style building, so the question then is whether to bother
with sourcing config.m4 or not. If we do deal wit it, the build
process with lots of Apache-provided modules will be faster, but if we
disallow config.m4 use for all DSOs we can limit our methods of
building any module to two:

  1. source config.m4, link with other .o files into server. There's
  no difference between this sort of module and a file in src/main as
  far as the makefiles go.

  2. run module's configure script (with autoconf, we can decide to
  point at our config.cache to make this faster), and run module's
  make routines to build a DSO. This degenerates to just using apxs
  like it's a third-party modules.

So by disallowing config.m4 for DSOs (and doing everything else I
mention above), we can consider all Apache building to consist of
compiling a bunch of .o's into an Apache binary, building some
libraries (PCRE, APR), and using apxs to build a bunch of modules.
Yeah, the compile will be slower this way, but this sort of
simplficaton holds a lot of appeal for me. 

C. Done through an apxs call, providing config.cache, a header file,
some other generated text file, or whatever. As much of this should be
stuffable into a header file. We should also strive to eliminate
things like compiled-in paths and such.

D. Here is where the automake decision gets made again. Is there any
hope of figuring out the compatibility problems and fixing them? ISTR
the main problem being that automake is slow, and likes to use
statements that only gmake supports, like its include statements.

If we don't go with automake, I still think we can make this part
really simple if we agree with everything I say above. 
If we decide not to go with automake, I still don't think building
Makefiles has to be hard.

I'd like to have a single top-level Makefile listing all of the source
files that are compiled directly into the server, including
src/mainish stuff and the non-DSO modules. Then that one makefile does
submakes only to take care of the PCREs and APRs and also uses 
apxs to build DSOs. In theory, it can be a pretty simple makefile,
with just some very long lists.

SOURCES = 75 .c files in a bunch of directories
OBJS = .o files

E. Easy with the scheme I describe above. Let's eliminate that
intermediate .a step. Even if we don't eliminate that step, it
shouldn't look too bad. We can concatenate Makefiles from subdirectories
to get a componentization affect without worrying about changing -I to
be ../../../.. instead of ../../../../..

F. We need to decide what to do for DSOs. I lean towards encapsulating
how to build DSOs into a seperate tool. Whether we use libtool,
dsotool, or something that is derived directly from Apache 1.3, I
don't really care too much, as long as the modules don't have to care,
because of APR abstraction or whatever.

View raw message