httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: RANT: Absolute Paths and configure
Date Mon, 03 Apr 2000 21:00:45 GMT
On Mon, 3 Apr 2000, Manoj Kasichainula wrote:
> On Mon, Apr 03, 2000 at 02:01:07AM -0700, Greg Stein wrote:
> > Python touches more points on the underlying OS than Apache, yet it has a
> > very clean I see no *inherent* reason for ours to be super
> > complex.
> Part of the problem is that we're trying to retrofit a configuration
> system onto something that didn't have one before. Now that the old
> configuration system has been removed, we can do some things to
> simplify the process (like eliminating the old ap_config.h). We're
> also not taking advantage of APR in places we should be, like thread
> detection.

Great. I believe that supports my hypothesis that the messiness is
transitory and that we *can* have a nice configure system. We're in
agreement yet again, Manoj :-)

> Also, the Makefile setup just feels too complicated to me. I've
> actually been pondering replacing everything with one single Makefile,
> and eliminating the recursive calls. That's harder to do when you
> can't rely on GNU make, but I think it would still be possible. Or, we
> could just bring back the old makefile generation code.

Have you seen the following paper?

  "Recursive Make Considered Harmful"

I presume you have since you mentioned Peter's Aegis system in other
contexts. But others may not have seen that paper.

(and no, I don't believe Aegis is a good long-term solution for us)

Back to the original point: I would support a top-level Makefile and a
script to generate the bugger. Effectively, you would do the recursion in
the generator, rather than during the make process. Since that script is a
developer script, it could be written in Perl (or Python! :-).

Note that you *might* do a little bit of recursion for third-party
modules. It may also be possible to mandate that third-party modules do
not participate in our build process: they generate a dynamic-load .so or
they generate a .a library that we statically link.

> > > And until the Software
> > > Carpentry guys come through (assuming that their implementation
> > > doesn't require Python on users' machines), there is nothing better
> > > out there that I know of.
> > 
> > It will require Python, by definition.
> For users as well? That's silly, unless their goal is to force more
> users to install Python or to only support Python-based apps.

That is not their goal. Their goal is to create a set of tools that are
devoid of the years of baggage behind autoconf/make/bug-databases/test-
frameworks. Essentially, they're looking to answer the question, "If you
were to write autoconf TODAY, how would you do it?" Also, they want the
implementations to be clean, maintainable, extendable, etc, and they
believe Python is the best way to achieve that.

Just start reading the FAQ entries at:

It also points out how they started with the basic precept of using a
scripting language (rather than C/C++) for the coding. Visual Basic, Perl,
Tcl, and Python were evaluated; Python was selected from that group. This
info is in the FAQ, too.

Of course, I'm a Python advocate, so I see no problem whatsoever with the
requirement :-). It was a very big point of contention on the SC
discussion lists, of course.


Greg Stein,

View raw message