httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: 1.3.7/1.4.0 Release
Date Mon, 21 Jun 1999 17:36:58 GMT

In article <199906211716.NAA26706@devsys.jaguNET.com> you wrote:
> Ralf S. Engelschall wrote:
>> In article <199906211353.JAA25467@devsys.jaguNET.com> you wrote:
>> 
>> > There's a few patches that are "supposed" to be commited. There's the
>> > mass-vhosting one and Ralf's EAPI for example. Ralf's 'mm' would be
>> > nice but we'd need to have it fit into the source since it's
>> > autconf driven right now :(
>> > 
>> > Unless someone else adds the vhost one, I'll do it late tonight.
>> 
>> I'll work on EAPI integration perhaps tomorrow.  Why is the Autoconf stuff of
>> MM a problem, Jim?  For inclusion of MM into the source tree all we have to do
>> is to strip the MM distribution to the essential files and call it's configure
>> script as "cd src/lib/mm && configure >configure.log 2>&1" in src/Configure
>> plus a few failure-checks after it and a " + configuring MM (please be
>> patient)" before.  That should be ok.
> 
> Hmmmm.... I'm thinking that having the mm source do it's own
> configuration is a layer of complexity we don't need. Most of
> what it needs to do and determine we already know. Not only
> that but it opens up that script to porting concerns (some GNU
> configure scripts blow up on some shells with "small" input
> buffers).
> 
> I think if we put it in 1.3.7/1.4.0 we should have it use what we've
> already provided. When we do 2.0, and if we use autoconf there, then
> it makes sense but right now I'm not sure.

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. 

Why? When you look at the MM configure.in you should be able to recognize that
MM uses Autoconf not just for fun. I've a few projects where I use Autoconf
just because I'm used to it, but MM is _NOT_ of this type. MM has to check a
lot of stuff and make non-trivial decisions. When you remember my first posted
patch for shared memory support in Apache, there were #ifdef's for MM which
were based on the knowlegde in ap_config.h. I've withdrawn this idea
immediately. You're too unflexible this way and do lots of incorrect
decisions. So I strongly recommend you to either like Autoconf at least this
time (you will do yourself a favor, doubt me) or you've to do a lot of work
with not clear results of final success. I'll not veto the non-Autoconf
approach, but I strongly advise you to not do this. We get more problems than
we try to avoid!

But perhaps this is only my opinion... ;)

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message