Re: [PATCH] APACI configure changes

["Ralf S. Engelschall" <rs...@engelschall.com>]

In article <x7...@montana.covalent.net> you wrote:

> The following patch changes/fixes the following items:

First let me say thanks that you started to work on this, Randy.  I appreciate
it a lot that someone actually worked on this to solve the requests some of us
recently made. But I've strong opinions on _how_ we should solve those
"configure vs. Configure" issues, so I'll give my feedback here, too. Sorry
for the delay.

> * Revert to old "--compat" format as the default. Use --GNU-paths to
>   get the "new" layout.

First the option --GNU-paths is too specific IMHO. We should provide a more
general option and perhaps additionally allow people to create their own
custom layout. Of course, the custom layouts are only a goody, but the option
should be named --with-layout=ID and --with-layout=FILE:ID for the goody case.

=> Suggestion: change --GNU-paths to --with-layout=GNU and let the
   Apache layout be selectable via --with-layout=Apache (see reason below).

Second I think the great idea (was it from Ken?) to force the user to specify
one layout option instead of silently changing the default layout sounds
reasonable. Just using the old --compat layout as the default now confuses
people again. And confusion is what we want to reduce and not to increase.

=> Suggestion: Make the default _NO_ layout and give an error message
   when the user didn't override this default. He should be forced to use
   either --with-layout=Apache or --with-layout=GNU _explicitly_. Only this
   way we can be sure that the user is sure what he does.

With these two changes, I can give my +1, of course.

> * Create a toplevel Makefile if using 'Configure' script. This helps
>   the "least astonishment" factor since we refer them to the toplevel
>   directory if they want to do a 'make install'.

-0, I doesn't like this intermixing of code between configure and
src/Configure. When you remember the goal of APACI was to make it _optional_
and in no way intermixed or merged into the src/Configure stuff (it wasn't
_MY_ goal, it was what the group said has to be the goal!). What you now do is
to move code from configure to src/Configure to make src/Configure half-APACI
like. This destroys all existing code seperations. And the exportation of such
a large amount of variables also makes portability problems (we had those
problems already).

=> Suggestion: When you really want to let src/Configure make use of APACI's
   features then do it the clean and modular way: Move src/Configure to
   src/Setup and create a src/Configure wrapper which calls ../configure.  The
   only issue here is the dealing with the -file argument. But that's not too
   complicated. At least this way no unclean code merging and functionality
   intermixing is done and the result is the same.

So, although +1 for the idea I've to vote -0 with a slight shifting to -1 for
the implementation way.

> * Only create the httpd.conf file and don't confuse the configuration
>   by creating the old stub files for srm.conf and access.conf.

Very good. +1 on idea and implementation.

> * Make use of $TARGET with APACI configure. $TARGET is then used to
>   base the name of the configuration file, pidfile, logfile, etc.

This is a reasonable idea, but the patch is not complete enough IMHO.  First
the TARGET then has to be part of src/Configuration.tmpl so the user can
change it by editing. Additionally the TARGET variable has to be supported by
APACI, too. 

Third when we change all httpd references in the installed files we should
also change the error messages. Currently we have a lot of error messages
which refer to "httpd: blabla..". When the user uses TARGET=apache messages
which say they come from the httpd program are confusing. So we should add a
TARGET #define into our httpd.h (which can be overridden) and change all
"httpd" strings to TARGET. Only this way it's not confusing. Because I already
see Marc arising and saying on c.i.w.s.u "Yes, these confusing error messages
are because some of us thought it's wise to provide a half-way renaming" ;-)

Forth shouldn't the libhttpd.* files changed, too? I think yes, because you
usually change TARGET to let you install a second variant of Apache (like
httpsd ;-) and then under SHARED_CORE you also need libhttpsd.* files instead
of libhttpd.* files or the whole TARGET fiddling is useless IMHO.

=> Suggestion: Make it more complete or (when it's too much to do)
   suspend the idea.

Finally I suggest to split this patch into four separate patches.  Because the
votings for the four parts are totally different.

I'll try to post those four (alternative) patches in the next hours which try
to implement my suggestions, too. So please don't hurry up. I really want to
see clean solutions and no quick hacks for APACI. Let us use some iterations
before we commit something.
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com