httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: Pause to Consider
Date Thu, 25 Nov 1999 07:49:52 GMT

In article <19991124212938.A25712@io.com> you wrote:
> Greg and Rasmus covered much of what I'd like to say.
> 
> On Wed, Nov 24, 1999 at 11:20:17AM -0000, David Reid wrote:
>> So, I guess what I want is for Manoj and Ryan (and all those who've helped)
>> to write down how the planned autoconf system will work.
> 
> Search the archives, I think from late last week. I posted a response
> to Ralf's request with as much design info as I had. There hasn't been
> any significant change since then. Other than that, I think the code
> speaks for itself best. Any questions you'd like answered?

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.

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.

Sure, I know I'm horribly not popular with this wish, because people want to
work on code immediately. But I still have problems to see how a different
approach can solve these old problems.

> I'm okay with not committing the changes for a while, but I don't
> think it helps anyone. Committing the files to the repository doesn't
> mean we've committed to autoconf. We can always cvs rm the files if
> we've decided the experiment was a total failure. And, I'm trying to
> make sure the old configuration scripts still work, at least for now,
> so we won't have lost any utility there.

Have you ever seen that we removed something non-trivial from the repository,
Manoj?  I only know a few smaller things from the last years. But we never had
removed lots of files after they were integrated. And I'm sure we will not
remove any Autoconf stuff again, independent how good it is.  Experience shows
that instead we like to patch and bash it for a longer time to get it actually
working. But the drawback is that this way some important issues (like the DSO
and APXS stuff) is again not well integrated, because the config/build
architecture originally missed it.

> My main motivation for committing the files quickly is so that other
> people can start changing them. Rasmus has some small nits which are
> really fixed most easily through CVS.

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?

> The only reason I can think of to not commit the files is that my
> methodology is significantly flawed, and we'd have a really ugly
> script set hanging around in the repository, being an embarassment to
> me forever. :) That's why I'm asking everyone for comments.
> 
> If people want a delay (speak up!), I'll wait, but otherwise, assuming
> my net access isn't too sporadic while I'm here (Framingham), I'll
> commit the changes in the next couple of days.

I don't want a delay in general. I personally just appreciate that
we first evaluate things externally and comitting it to the final
repository only after enough consideration, cleanup, etc. Because once
something is comitted to the final repository the borders smooth (APACI
was a good example: if I had comitted it too early it would have merged
too much with src/Configure). And I see the same problem with the Autoconf
stuff, because configuration and Makefiles, etc. all are related.

So my wish again: please open an apache-playground/ module, place a
src/main/httpd.c (representing the core) and a src/modules/foo/mod_foo.c
(representing a module) there and add whatever config and build
environment you think is appropriate and required. Then let people
review it and enhance it until we see that it addresses all important
issues. And general important issue IMO is: Whether src/modules/foo/
exists or not has to be unimportant to the config/build environment,
i.e. it has to find it automatically if it exists and has to treat is it
_would_ stay _outside_ the source tree (even it _can_ be _inside_).

The last days I've explained a little bit more of this to some of us in a
private mail. I append you the core part of my reply above.

Yours,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com
_______

A new approach IMHO should treat both building situations 100% equal.
For this IMHO one has treat internal building of modules equal to
external building, i.e. even modules _inside_ the source tree are built
as they would stay _outside_. Through which script/facility/whatever
is still not important. But only this way our contributors can develop
modules (externally) and we overtake them later (as internal ones), etc.
And only this way one can reduce the build environment complexity of
modules. Look at mod_php, mod_perl and mod_ssl: all have great trouble
to support internal _and_ external building at the same time. And each
one does it slightly different and more or less good.

I know that people usually don't think about these things, because they
treat Makefiles and the build process independent of Autoconf and the
configuration step. But that's not really the case if one looks what
modules need. Actually currently my idea for a clean build environment
looks like 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
   configure.in 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).


Mime
View raw message