httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Pause to Consider
Date Thu, 25 Nov 1999 11:37:04 GMT
This is getting insane. Just how many barriers do people want to put in
front of Manoj? He has stepped up and committed to getting autoconf done.
We will see the work he is doing in the CVS tree and can comment/correct
it as he works. We can point out holes in design so that Manoj can think
about how to fill them in.

Creating a separate tree only serves to make sure that nobody else will
use the stuff. Who is going to check out yet another version of Apache?
Get real. If autoconf goes into the 2.0 repository, then it will get used.
If it goes elsewhere (whether a skeleton repository or a full blown copy),
then it won't.

We have few enough people doing *real coding* to justify putting in more
barriers to getting work done. I'm a guilty party... I sit on the
sidelines taking pot shots at Ryan :-). I'll dig in when mod_dav hits 1.0,
but I'm sure there are numerous others in the same situation -- a desire
to help code, but the time just isn't there. I don't want to see barriers
for people who *do* have the time and inclination.

Ralf says "but it won't get removed if it doesn't work." Well, I don't see
"not working" as an outcome, so ignore that issue. autoconf is one of the
best ways to minimize the amount of work that we put in for portability
(APR is another). I don't think it would be in our best interests to *not*
use it, so it behooves us to get our system running with it.

Personally, I haven't had an opportunity to look at the stuff. If it comes
across the checkins mailing list, then I definitely will. (although maybe
I should... the thought of requiring every module to create a .m4 or a feels wrong)

Anyway... I say, don't put barriers into the system. Make it easier to
work. Manoj should check in the stuff. He'll get it working and people can
contribute their ideas and suggestions just like we do with all the other
things that go into the code.


On Thu, 25 Nov 1999, David Reid wrote:

> How about we go one further?
> This is just a suggestion, but maybe it has merit...
> First we take a copy of the apache-2.0 tree and put it in CVS as
> 'manojs-playground' or some such.
> Next we get as many people as possible to checkout a copy and make sure that
> it builds on as many platforms as possible.  The aim is to arrive at a
> "known" entity of code that will build if we get the environment correct.
> We set a cut off date for this and after that date we don't touch the source
> code except for changes necessary to support the autoconf structure.
> Manoj can now do whatever he feels like to get the new architecture in
> place.  With no source amendments it should be easier to keep track of
> what's going on and Manoj doesn't have to worry about anything.  One
> directory per module, just do it!
> Why?
> 1.  We all know and love the apache source tree so it's easier to view the
> changes against a "known" tree
> 2.  As a group we know a lot about the problems and so can gauge whether or
> not the new stuff works easier
> 3.  Manoj can works as fast as he likes without anything to hold him back.
> He can commit code and we can review it without the fear of it just being
> patched until it suffices
> My concern with Ralf's suggestion is that it could "mask" some of the
> problems by being overly-simple.  At least using the full source tree we get
> all the baggage/issues that we have been talking about over the last week or
> so.
> Another 2p...
> d.
> ----- Original Message -----
> From: Ralf S. Engelschall <>
> To: <>
> Sent: 25 November 1999 07:49
> Subject: Re: Pause to Consider
> >
> > In article <> 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
> > 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
> >                              
> >                              
> > _______
> >
> > 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
> > 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).
> >

Greg Stein,

View raw message