httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: Configure vs. configure: Please read
Date Wed, 02 Dec 1998 07:58:28 GMT

In article <> you wrote:

> I'm sure a few folks are getting tired of this debate... Please give
> some feedback and hopefully we can bury this.

> Issues:
>  * Confusion as to which method to use

My opinion: One one single method, yes. So I support your merging idea in
general. The difference is just that some people use this method as
"./Configure -file" and others with APACI options.

>  * No toplevel Makefile created by Configure

My opinion: Not really necessary, but ok.

>  * code duplication

My opinion: Currently there is no real code duplication, isn't it?

>  * portability

My opinion: I'm 99% sure APACI's configure script is as portable
as src/Configure.

> The approach I am contemplating to this is to move the existing APACI
> 'configure' into the src/ directory as 'Configure' and merge the needed
> bits from the old 'Configure' into the APACI 'configure' now named
> 'Configure'. Replace the APACI 'configure' in the toplevel directory
> with a wrapper that essentially is: "#!/bin/sh . src/Configure"

> I then see using 'basename' to determine how the script was called and 
> emulate the 2 different behaviors from one script.

Hmmmmm... sorry to say this, but although this is a cleanup idea and I like it
in general I've one problem with it: Such a merge is _VERY_ error prone,
Randy. When you really succeed, I'm happy and give you my +1 as long as the
current APACI functionality completely remains. But although I personally know
both the internals of configure and src/Configure I would not try such a merge
myself at this stage. Why? Because although I've already cleaned up
src/Configure it's still not as clean as it can be (we have still some subtle
problems because of the order of checks, etc.). And when you merge in
configure it gets not really better, I guess. So, be _VERY_ careful here,
Randy. When we break something we loose totally. 

> This should solve the toplevel Makefile issue, code duplication issue
> and will address portability concerns about APACI. The confusion issue 
> is going to need to be resolved by the group through attitude and
> documentation.

> I do think that we need to start encouraging people to use APACI as it 
> solves a few issues that the old Configure does not. I might point out 
> that I was one of the people that voted against including APACI in 1.3 
> originally, but now that we have it, I think we need to start taking
> advantage of it.

Sure, but the only "advantage" of APACI for our "fighting-against-APACI" guys
is the installation procecure (for some of us not even that ;-). So I'm still
not conviced whether it's really necessary to merge such a lot of code.
Perhaps there is another tiny and elegant solution? Hmmmm... I think we should
give us the time for more discussion. Currently we have a lot of issues and a
lot of ideas. But only a few of us have given their opinion.  And I see it
coming that any too large change for 1.3.4 causes us more problems than we
want to have. So for whatever we do we should be very carefully and vote on
the direction before doing it to make sure we go to the right direction.

> Personal issues:
>  * It is not that important to me that Configure creates a toplevel
>    Makefile.
>  * I don't have time to do this if there is not support to commit it.

> If I get 3 quick +1s on this, I'll start working tonight.

I would wait a little bit longer, Randy. You don't know the opinion of others.
And nothing is more frustrating than a last-minute -1 from someone just
because you were too fast in hacking. 

I think you need at least a final group decision for these questions in order
to implement a solution (or any solution will be finally vetoed by someone):

1. Can we rely on APACI's configure code from a portability point of view,
   i.e. can we use some code from APACI in a merge between configure and
   src/Configure without loosing portability?

2. Can we forget the separation between APACI and src/Configure,
   i.e. can we smooth/merge the code or do we need strong seperations because
   APACI is considered as a pure optional feature.

When the group decision/answers for 1.) and 2.) are both "yes", you can start
hacking on your merging idea. Because then you have the general support of the
group and a -1 will only occur for some technical details. But unless you have
a common "yes" to 1.) and 2.) any attempt into your merging direction will
fail, IMHO.

I'm personally happy with both keeping the current state and doing a merge
(unless it's done very carefully and clean, of course). But my sanity says to
me that it's better for 1.3.x to mainly keep the current state and instead try
only a minimal confusion-reducement solution unless the merging is done in a
very fantastically clean and portable way. And because I would not try such a
merge myself I'm not conviced whether it's really wise to try such a merge...

In the meantime let me think about smaller solutions to the proposed
confusion-situation. Perhaps there is one we just have not found.

As I see it, we have only two proposed problems:

   * Confusion as to which method to use
   * No toplevel Makefile created by Configure for installation

So how about this:

1. We rename src/Configure to src/setup.
   => This way we prevent any more Configure-script confusion (they can only
      find _ONE_ configuration interface) and we don't provide a configuration
      method in the src/ dir because both installation happens at the
      top-level and also the user expects a configuration script there.

2. We change APACI's configure script to recognize
   the -file option: When it's used (or no option is given at all!) it does
   nothing more than creating the top-level Makefile and _immediately_ running
   => This way the configuration interface provides both known
      interface types. The only difference is that it's called from the
      top-level. But as already mentioned this is useful because installation
      happes from there, too. And it's common practice to have configuration
      scripts in the top-level of a package.

3. We change any references to src/Configure in the documentation
   to the top-level configure script.
   => This is to avoid the confusion any longer.

This is a mininal change and solves the problems, too.
And IMHO it has the following benefits to the merging approach:

o We don't merge code, so the patch is not error-prone.

o We don't change the source tree configuration process because the script
  remains the same (just is renamed to src/setup). So no new portability
  problems can occur.

o We change src/setup to what it really is: A script which is the work horse
  of setting up the source tree. It was never a real "interface", IMHO.

o We still provide all functionality and are backward compatible
  without having to hack a lot.

                                       Ralf S. Engelschall

View raw message