httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <man...@io.com>
Subject Re: [PATCH] configure.in.in
Date Tue, 14 Dec 1999 07:07:33 GMT
On Tue, Dec 07, 1999 at 12:15:13PM +0100, Sascha Schumann wrote:
> On Tue, Dec 07, 1999 at 01:51:28AM -0500, Manoj Kasichainula wrote:
> > The attached patch gets rid of a minor hack that I stole from PHP4,
> > and replaces it with a somewhat more major hack. Please comment on it,
> > especially you PHP guys who wrote the original hack. Please cc: the
> > php list if you think this is appropriate, since PHP could make a
> > similar change.
> 
>     We had exactly this approach before. We dropped it because
>     always generating all ext/*/Makefiles does take a lot of time
>     (we are at ~50 extensions). automake is wrong, because it
>     assumes a static list of filenames in AC_OUTPUT.

Apache doesn't have this problem, yet. If we do split out each module
into its own directory (which doesn't seem so necessary anymore given
the intrastructure that's now in place), then it's a real factor to
consider. It's one of the reasons I haven't actually committed this
change yet; renaming files in CVS gives me the heebee-jeebies, and
having to rename them back because the new system is too slow gives
them to me twofold.

Hmm, I just had a thought. If we don't actually recurse into every
directory and generate makefiles for all of them, then make clean,
make depend, etc. won't work, right?

Let's say I compile with one set of modules, then compile with another
set, then make clean. The modules that were only in the first compile
wouldn't be cleaned out. I think this is enough reason, in Apache's
case, to generate them all.

>     First, automake's warning are generally useless (because they
>     are based on too narrow assumptions).

That's true. When I tell automake to --add-missing, why does it still
whine about missing files?

> Having one more useless warning hardly bothers me. 

That warning though does seem to serve some purpose. Certain things do
break (such as --enable-maintainer-mode and make dist) because of it.
You can blame automake for this, of course, but it's still true.

>     Second, this does not affect the normal use of the build
>     environment. There are some issues in maintainer mode, but
>     the effects encountered there are bearable and limited to
>     maintainers (aka developers).

Yeah, if you don't make use of all the fancy automake features.  I
personally like to take advantage of features of other packages when
possibile rather than writing my own.

I think I'm close to getting make dist working using just the automake
built-in features, without much extra work in the Apache makefiles at
all. And --enable-maintainer-mode is really cool! :) If automake will
do this stuff for us, then I'm happier, because it's less work for me.

> > With this, the build.mk in PHP4 shouldn't be necessary, because
> > automake seems to know how to handle all that stuff. make dist almost
> > works (and I think it can work completely in the Apache tree once I
> > fix a few errors I made).
> 
>     Wrong. build.mk does a lot more (i.e. checking tool versions,
>     running only the required set of tools, preserving our custom
>     libtool files, et cetera). 

I'd like to steal it for Apache, too, but I couldn't find it.

I'm working on making maintainer-mode do all the custom things Apache
requires, like PHP4's build.mk does.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/

Mime
View raw message