httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rasmus Lerdorf <>
Subject Re: Pause to Consider
Date Thu, 25 Nov 1999 11:30:57 GMT
> Yes, how do you plan to address the apxs issue? That is, how to you plan to
> integrate your Autoconf approach with the functionality of the old "build
> modules externally [via apxs]"? Currently it looks to me you've still not
> thought about this, because you have direct references between your Autoconf
> stuff and the modules (you do a "cat *.m4" mainly).  This breaks for modules
> which should be configured and built externally.

Well, we have actually thought about it.  I don't quite understand why you
think the "cat *.m4" stuff would break apxs in any way.  The way both
mod_perl and mod_php use apxs there is no problem here.  All we need is an
apxs script that can tell us the right compile flags, where to install to
and where to find header files.  Both mod_perl and mod_php are configured
externally and there is no need, nor is there any desire, to have Apache's
configure mechanism mesh with these external configure mechanisms.  At
least not from my perspective.

> I think this issue is important if we want to avoid again a situation as for
> 1.3 where modules have to provide different build environments and
> adjustations just to be able to config/built inside and outside the Apache
> source tree (look at mod_php, mod_perl and mod_ssl: they have to do lots of
> fiddling to support this). I would appreciate that the new config/build
> environment addresses this already from the start.  Or it will again lead to
> the inconsistent stuff we now have with 1.3.  That's why I had appreciated
> that the whole config/build env is first specified in a text file so it can be
> discussed better.

I guess your main issue here is that you want the ability to drop an
external module into the Apache source tree and have it mesh easily with
the Apache configure mechanism.  It seems to me that the "cat *.m4" might
actually help you here then.  The module just needs to provide a simple
config.m4, a 3-line and a config.h.stub file and Apache's
buildconf should pick it up.  In this case apxs doesn't even come into the
picture.  Or perhaps I am missing your point?

> So, I see your point of committing early to allow people to work on the stuff.
> But I also see the risk that we again get just a half-way solution at the end
> and need lots of months to make it complete. So I personally still think, we
> could combine both: open an apache-playground/ module in CVS and commit the
> stuff there. Then people can work on it and if it fails it doesn't have to be
> integrated at all. If it succeeds (i.e. it addressed all important issues and
> works fine) we can finally commit it to apache-2.0/. How about this?

Why can't people review the stuff in the tarball/diff format Manoj has
already posted?  So far nobody has actually come up with any sort of
constructive feedback on what Manoj has done so far.  Why would creating a
separate cvs tree change this?

> 1. Apache configures its core part via Autoconf. This implicitly creates a
>    global config.cache and a special script, say it is still named apxs.
> 2. Apache internal modules now run an own Autoconf step for their own
> skeleton file, but this (for speed!) uses the global
>    config.cache and even contributes to it on-the-fly. For building
>    it uses the (uninstalled) apxs script.
> 3. Apache external modules do it exactly the same
>    as internal modules, but just with two differences: They find the
>    config.cache not inside a source tree, they find it in an installation
>    location. And they do not write back their values, of course. They just
>    read it.  And for building they also use apxs, just the path to it is not a
>    path to a source tree of Apache, it's the path to an installed version of
>    apxs.
> This way we achieve both flexibility (modules can use whatever Autoconf
> features they want and need; can be build internally and externally;
> etc.) and reduce complexity (the build environment of modules gets a lot
> less complex) while we still can have a fast configuration step (because
> of the shared global config.cache file).

Great, post a tarball/diff of this implementation and we can try it out.


View raw message