httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: [PATCH] Configuration (3/4): APACI Makefile for src/Configure
Date Tue, 01 Dec 1998 15:08:53 GMT

In article <> you wrote:
> Ralf S. Engelschall wrote:
>>   o APACI's configure script is enhanced to allow a --with-template=FILE
>>     option. The default for FILE is src/Configuration.tmpl. 
>>   o the src/Configure script is renamed to src/Setup (don't know whether this
>>     is a good name, it's not important) and APACI's configure script now calls
>>     src/Setup instead of src/Configure.
>>   o a new wrapper script src/Configure is created which provides
>>     again the -file FILE option. FILE here defaults to Configuration.  It does
>>     nothing more than running APACI's configure script with this file by using
>>     --with-template.

> As I understand this, this means that running Configure will actually
> run configure?

> I'm not sure if I think this is a Good Idea. In fact, I think it's a Bad
> Idea. One reason is that for people (and platforms/OSs) that have never
> run configure, they will now be doing that, and this will cause problems.
> Why? Configure was "designed" at the beginning to use the base, low
> level capabilities of the System 7 shell. And it's been held to that
> limitation since then. Sure, that's maybe stupid, and it results in
> code that's not as elegant, but the desire was always that it runs
> on as many OSs and with as many shells as possible. configure, AFAIK,
> does not have that limitation, and maybe has not been so rigorously(sp?)
> looked at to "make sure" it complies. So for some platforms, Configure
> may work fine, but configure will barf, and forcing Configure to run
> configure opens up problems.

Remember that we've still not a single PR that configure failed on a platform
where Configure worked. And was written with the same restrictions in mind. We
extra avoided any shell functions and other non-portable stuff....

> Secondly, the whole idea of configure was to provide a front end to
> Configure. But now this is being totally reversed. Instead, Configure
> is a front end to configure which drives Setup. Why is this better
> than configure driving Configure?

It isn't. All this patch tried to do is to present an alternative solution to
an idea which is not from me. It was the idea others that although
src/Configure is used an APACI Makefile should be created. So, all I say is
"when you want this then _USE_ APACI but don't _MOVE_ stuff from APACI into
src/Configure". So, I _PEROSONALLY_ want neither this patch nor the part
inside Randys patch. I think we should keep it as it is.  But when people
insist on having a top-level Makefile the half-APACI way then it's better to
do it the whole-APACI way.

> I think I'd have to +1 Randy's and veto this one, unfortunately...
> I think that the compatibility problems and the increased "layers"
> and "cmplexity" aren't worth it, and provide no real benefit.
> Some would argue that it's also a way of "forcing" configure to
> be the official build suite, with no discussion or group consensus
> in the matter as well :) :)

Fine, accepted. +1 for not using this patch also from me, too ;-) But still -1
for Randys "code moving patch" from my side, too. Because the variable
mass-exportation is too problematic and the code movement is against the
original separation-idea and is also a little bit unclean. 

So, as it looks to me, best is to keep the current state and don't try to
generate the top-level Makefile from within src/Configure. I'm +1 for keeping
the current state.
                                       Ralf S. Engelschall

View raw message