httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <ab...@dial.pipex.com>
Subject Re: Pause to Consider
Date Thu, 25 Nov 1999 09:15:56 GMT
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 <rse@engelschall.com>
To: <new-httpd@apache.org>
Sent: 25 November 1999 07:49
Subject: Re: Pause to Consider


>
> 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