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: Working on autoconfing Apache 2.0
Date Thu, 18 Nov 1999 14:28:16 GMT
Sounds like such a good idea that I'm sure Manoj will oblige...

Manoj?

d :-)
----- Original Message -----
From: Ralf S. Engelschall <rse@engelschall.com>
To: <new-httpd@apache.org>
Sent: 18 November 1999 10:10
Subject: Re: Working on autoconfing Apache 2.0


>
> In article <19991117151510.A1465@dosa.raleigh.ibm.com> you wrote:
>
> > FYI, I'm attempting to build an autoconf/automake/libtool setup for
> > Apache 2.0. I'm essentially taking the PHP4 configure stuff and using
> > that as a basis for the work.
> >
> > My plan is to try as much as possible to build the auto* stuff into
> > the existing structure, so that until it works well, someone can
> > either use the old configuration routines or auto*.
> >
> > Once the new config stuff works well enough to not get in the way of
> > coding, we'd throw away the old config stuff, and then clean up the
> > locations of files to fit more naturally into autoconf's way.
> >
> > One thing that I may want to do now, though, is move each module into
> > its own directory. It makes per-module configuration far simpler, and
> > makes the m4 code to add a module to the compile more uniform. I'm
> > trying to find a decent way of pulling this off without rearranging
> > that part of the tree right now, but this might be a difficult
> > exercise.
> >
> > Any objections to any of the above? Suggestions and help are of course
> > very very welcome.
>
> [I know that I'm boring with my cleanness advices, but...]
>
> My only suggestions is that it would be very nice if the particular
approach
> is first written down in a little text file which we can use to discuss
> various issues. The whole Autoconf stuff for Apache 2.0 is _HORRIBLY_
complex
> if you want to cover mostly the same features than the old scripts (at
least
> that is what I concluded after thinking about it a few times). So it is
> wise to first write down what should be kicked out, what should be still
> provided and then especially _HOW_ this should be provided within
> Autoconf. Additionally I strongly recommend you to not kick in any
> Autoconf stuff before you've not very carefully evaluated the ingredients.
> Else you'll have to fix it forever.
>
> I don't know whether you're an Autoconf expert or not, but I consider me
an
> Autoconf expert but nevertheless I would not trust me to make Apache 2.0
use
> Autoconf in a _CLEAN_ way without _FIRST_ specifying exactly how it should
be
> done and evaluating things _EXTERNALLY_. Autoconf is a great hackers tool,
but
> if one isn't very carefully it gets a horrible tool in practice for
> maintainance and bugfixing (sh can be mess, m4 can be a mess, both
together
> can cause real chaos).
>
> For instance, it took me already months to make the Autoconf stuff of a
small
> project like GNU Pth very clean and maintainable. So you can expect even
more
> for Apache 2.0. And it will work only in the long-term only if it's done
> cleanly from the first step. So I personally would appreciate not to kick
> in something existing. Instead please first let us decide how it should
> be done, then evaluate the parts externally (in a scratch source tree) and
> then assemble the pieces.  Especially do a little bit more evaluation than
> just looking at one project. There are more good Autoconf usages out
> there. Grab the best of each project.
>
> If we decide to do it not in a rush and instead very slowly and carefully,
I'm
> willing to also help out here. Because I think this topic is again very
> important for the success of Apache 2.0, as APACI was an important step
for
> Apache 1.3.
>                                        Ralf S. Engelschall
>                                        rse@engelschall.com
>                                        www.engelschall.com


Mime
View raw message