httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@devsys.jaguNET.com>
Subject Re: Apache 2000, err Apache 2.0 gets real
Date Sun, 01 Aug 1999 13:33:13 GMT
Ralf S. Engelschall wrote:
> 

I'm sorry... I simply can't resist. I plan on keeping this
and doing a global Automake -> Autoconf and Makefile -> "configuration
script" when people ask my opinion about Autoconf :) :) :)

Seriously though, the problem that I have with autoconf and the
like is that they give a false sense of security. They seem to say
"Ok... we'll take over now, just you hush up". Then they have a
weird mix of env vars vs. command-line options which makes it
even harder to understand. Basically, unless "./configure" works
for you as is, you're going to have a tough time.

Also, there are 2 tendencies that I see in most autoconf-based
packages:

   1. The idea that because autoconf is being used, "we" no
      longer have to deal with any OS-specific stuff or
      nasty shell programming. For something as complex
      as Apache, that's simply not the case.

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

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.

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

PPS: Is the current Configure process ideal? Not at all. It requires
     some extensive cleanup. But at least it does show that (1)
     we've been able to have it do whatever we've needed it to do
     and (2) many of the changes that have been made don't get
     addressed by 'autoconf' anyway.

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.

Cheers!


-- 
===========================================================================
   Jim Jagielski   |||   jim@jaguNET.com   |||   http://www.jaguNET.com/
            "That's no ordinary rabbit... that's the most foul,
            cruel and bad-tempered rodent you ever laid eyes on"

Mime
View raw message