httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: Apache 2000, err Apache 2.0 gets real
Date Sun, 01 Aug 1999 13:58:59 GMT

In article <> you wrote:
> Ralf S. Engelschall wrote:

> [...]
>    2. That autoconf is used "for portability reasons" but
>       the other various required shell scripts (and there are
>       always additional ones needed) almost without a doubt
>       ignore portability. Just a few days ago I went to install
>       libtool 1.3.3 on an old machine. The ./configure script
>       overloaded the small 'sh' buffer, so I needed to force
>       it to use 'ksh' (this is more common than you think).
>       But anyway, the 'make check' and 'make install' failed!
>       Why? Because they used non-portable options to 'egrep'
>       and 'cp' !

Ok, that's not nice and should be fixed, of course. Nevertheless installing
libtool is not the task of the end user of a package based on libtool. It's
just the task of the developer who is using libtool for the package. Inside a
source tree I've over the last years never seen a libtool script which failed.
Yes, I've to admit that the shell script contents is of libtool is ugly, but
it at least is well-tested and works fine...

> As I mentioned before, if we decide to go autoconf, I plan to
> work very hard to address my concerns so that, as much as possible,
> Apache will not suffer from the failings I see in so many autoconfs.

Fine. But let us keep in mind that these observed problems are problems of the
packages _using_ Autoconf and not an inherent problem of Autoconf itself IMHO.

> PS: As an aside, if we feel that we need something like shtool, I would
>     prefer Apache releasing it's own "helpers" package.

<grin> Why? What do you expect to gain from this? Why do you still dislike
shtool so much, Jim?  I think this is an opinion based on non-technical
issues, right?  If it's a license-based issue (GPL), then you have to complain
also about Autoconf and Libtool, of course. And if it is neither non-technical
nor license-based, what's the actual problem, Jim? 

Even with the latest GNU shtool 1.4 the old argument (was it from you or Ken?)
``shtool is a large script where we just need a few ingredients'' is gone:
With `shtoolize' you can generate your own custom `shtool' scripts (for
instance for the current Apache you would do ``shtoolize -o shtool mkdir
install path guessos mkshadow'').

> [...]
>      and (2) many of the changes that have been made don't get
>      addressed by 'autoconf' anyway.

Can you give an example from our config stuff which you think we can't easily
do with Autoconf?

> PPPS: Do I plan on resisting autoconf? No. I just want people to
>       make sure they realize that it's not a magic elixer. It's
>       a very neat package and used wisely, solves about 90% of
>       the work. But it doesn't do it all.

Yes, fully agreed!

That's why I appreciate that we don't try a quick "translate all to Autoconf"
for Apache 2.0.  Instead especially for the module config and build process
and DSO situations we should create a well-considered environment.  And I'm
convinced Autoconf is not all we need here. I'm even convinced that the
"configure" script(s) should be not directly the ones generated by Autoconf!
Instead the Autoconf scripts should be run in a special environment in the
background of our own "configure" scripts.  But ok, it's too early for those
                                       Ralf S. Engelschall

View raw message