httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <ra...@Covalent.NET>
Subject Re: cvs commit: apache-1.3/src/support Makefile.tmpl apxs.pl
Date Wed, 02 Dec 1998 18:35:19 GMT
Marc Slemko <marcs@worldgate.com> writes:
> On 2 Dec 1998, Randy Terbush wrote:
> 
> > "Ralf S. Engelschall" <rse@engelschall.com> writes:
> > > In article <19981202000021.17610.qmail@hyperreal.org> you wrote:
> > > > randy       98/12/01 16:00:20
> > > 
> > > >   Modified:    .        Makefile.tmpl configure
> > > >                src      CHANGES Configuration.tmpl Configure Makefile.tmpl
> > > >                src/include httpd.h
> > > >                src/main http_config.c http_log.c http_main.c util.c
> > > >                src/modules/proxy proxy_cache.c
> > > >                src/modules/standard mod_include.c mod_log_agent.c
> > > >                         mod_log_config.c mod_log_referer.c mod_mime.c
> > > >                src/support Makefile.tmpl apxs.pl
> > > >   Log:
> > > >   Fix TARGET configuration when configuring and installing using
> > > >   APACI configure. TARGET now defines the basename of the configuration
> > > >   file, startup script, manual page, etc. log_error_core() now reports
> > > >   the server binary name given by argv[0]. TARGET can now also be defined
> > > >   with --target=TARGET parameter passed to APACI configure.
> > I would prefer to deal with this with some documentation. If we don't
> > do these two changes, we give them the car without the keys.
> 
> There is no way you can deal with this in documentation.  I really do
> NOT like magically changing the names of things.  That was never 
> presented as part of this change, and makes it even worse.  

The only thing in this case that receives a name change is
apachectl. If the default binary name was 'apache' then it would not
change.

> There are things that can use cleaning up, but it is NOT appropriate
> to do a half-assed job of it and it is really not appropriate to go
> crazy in 1.3.  Even worse than having two interfaces for doing things is 
> randomly changing the defaults for no reason.  

Seems that we would be doing a "half-assed job" by not providing a
startup script for the new target name. An alternative would be to
change apachectl to allow us to pass the server binary name. But that
seems to be more confusing to me than to have separate startup
scripts.

> I have very very very rarely seen anyone having trouble with 
> multiple installations in one directory or whatever the rationale for 
> this change supposedly is that would be helped by this.  If anything,
> they would just be far more confused.  
> 
> The whole idea when this started was that having arbitrary odd paths
> used by configure that one person just made up is a problem.  Now
> we are just changing it to other arbitrary odd "paths" and like things
> that someone else made up.  

No. There were two issues here.

1. The path issue
2. The TARGET name issue.

Your complaints seem to be with the TARGET name issue. The TARGET
functionality did not exist in APACI configure. We move this
configuration issue closer to close by resolving that. It seems to me
that the changes that went in can be supported by logic and I can't
see where arguing for the status quo helps resolve these
inconsistancies.

> I do not see the problems that warrent a lot of this changing to try 
> to make things perfect, and do not feel it is appropriate for 1.3.x.

Seems we are really talking about one minor issue here that I think we 
can reach agreement on. If you are really set on keeping the startup
script named apachectl when the default target is used, that is easily 
fixable, but I do think that we need to be creating some other file
names when the target is not the default.

-Randy


Mime
View raw message