httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: 1.3.7/1.4.0 Release
Date Mon, 21 Jun 1999 17:56:37 GMT
Ralf S. Engelschall wrote:
> That's why I personally always suggested to not integrate MM into the source
> tree and instead use it externally as I do it currently. Although it would be
> very useful to have it in the source tree. But I knew that you and others
> would argue this way against the Autoconf stuff. But I can only vote -0 for
> this non-Autoconf approach. 

As long as nothing depends on MM, I have no problem with it staying
a non-official 3rd party "extension" to Apache.

I'm not arguing against autoconf though. It's the timing only.
Having 2 separate [Cc]onfigure interfaces is bad enough but to
add another totally seperate configuration build process inside
is too complex IMO _at this stage_.   :-) :-)

OT: Our present setup, as nasty as it does, does give us some
    level of "control" over which OSs Apache runs on. What we
    are saying, in effect, is that "We've tested Apache on these
    platforms, which we know of and have access to." Of course,
    it's not that reliable, since some are ports from outside and
    may not/are not being maintained. But if someone tries to
    build Apache under Foobix v9.65 then the current Configure
    process will let them know "We have no idea what that is...
    you're on your own" and "protect" us from Email and stuff
    saying "Hey, it's not working under Foobix!" Autoconf
    basically implies "Yeah, it'll work for you" which then opens
    us up to "Hey, it didn't work under Foobix!"

    I don't know why people think I'm so anti-autoconf. It's
    a nice tool and it does a fine job. My only "beef" against
    it, I guess, is the belief that it solves ALL porting and
    compatibility problems and it simply doesn't. I'm certainly
    not going to "fight" against the possibility of moving to
    an autoconf-type setup for Apache 2.0. But using autoconf
    efficiently is a long and hard learning curve, much more
    so that simple shell programming (esp. if we get rid of the
    stupid "on v7 shell capability restrictions). 
   Jim Jagielski   |||   |||
            "That's no ordinary rabbit... that's the most foul,
            cruel and bad-tempered rodent you ever laid eyes on"

View raw message