httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <ra...@Covalent.NET>
Subject Re: Configure vs. configure: Please read
Date Wed, 02 Dec 1998 16:12:42 GMT
"Ralf S. Engelschall" <rse@engelschall.com> writes:
> >  * 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?

There isn't so much now, but the confusion is there for a developer or 
vendor who wants to add to the functionality. Which system do you use
and where do you add the code? I think that consolidation solves some
of that problem and might help in transitioning from Configure.

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

I would tend to agree with you. I'm actively supporting it on 16
different platforms. Seems to work in every case.

> > 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. 

Believe me, I understand the weight of this change. So far, I think we 
are doing ok with these latest changes. This one worries me the most.

Actually, after dancing with this thing late into the night, I think
there may be a more simple solution to the toplevel Makefile issue,
but still leaves the two separate chunks of code that I would
personally like to see merged to remove some of this debate. That
other solution lies in the Makefile.tmpl for the src/ directory and
simply building on the install: target. 

> 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.

No. If I thought that removing Configure was an option, I would, but
people will expect it to be there. We need to make the merge
transparent. This needs to be done for 2.0, but not 1.3.x.

> 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
>    src/setup. 
>    => 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.

Actually, the more I think about this, it is a rediculous amount of
work to go to to make Configure do an install: target. Furthermore, we 
add to the confusion by having to configuration methods that do the
same thing. I say that we change the install target in the
src/Makefile.tmpl to give more information about how to configure
Apache *and* do an install and call it good.

-Randy




Mime
View raw message