You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2001/04/03 22:00:01 UTC
new /usr/local/apache2 usage, --prefix, and make install
On Solaris and Tru64 (and maybe more), my --prefix is getting ignored
and instead make install is trying to put stuff in /usr/local/apache2
:(
looking at it now...
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: new /usr/local/apache2 usage, --prefix, and make install
Posted by ed...@apache.org.
On Tue, Apr 03, 2001 at 01:42:17PM -0700, Marc Slemko wrote:
> Hmm. It is a bit of a mess trying to figure out how autoconf's
> installation prefixes and stuff like config.layout should play together
> nicely. Note that I'm pretty sure they didn't work "right" before either,
> it just wasn't wrong in such a visible way...
Working with autoconf is indeed somewhat unpleasant. I've spent some
time looking around (.in and .m4 files spread out all over), and testing
various things. After all this, I'm still somewhat of the opinion that
the layout system and the autoconf directories stuff conflict ... they
shouldn't, but the way autoconf deals with those, it's hard to fix the
interactions to work as you described.
The basic problem is that the autoconf directories stuff comes from
/usr/share/autoconf/autoconf.m4f (in my system; I'm guessing the name
may vary, though the contents are likely to be similar if so). It seems
to go into the generated configure file before anything which you
specify, and it both assigns defaults and then takes arguments on the
command line. Here are the variables in question:
prefix=NONE
exec_prefix=NONE
srcdir=
bindir='${exec_prefix}/bin'
sbindir='${exec_prefix}/sbin'
libexecdir='${exec_prefix}/libexec'
datadir='${prefix}/share'
sysconfdir='${prefix}/etc'
sharedstatedir='${prefix}/com'
localstatedir='${prefix}/var'
libdir='${exec_prefix}/lib'
includedir='${prefix}/include'
oldincludedir='/usr/include'
infodir='${prefix}/info'
mandir='${prefix}/man'
(We add a few others, which are easier to deal with). I'm not even sure
these defaults will be the same on all OSes, let alone all releases of
autoconf. AFAICT, no record is stored of which ones were overridden on
the command line.
So -- I see the following options (of them, I dislike 2a the least):
1) We could have layout override options specified on the command line
(excepting prefix and exec_prefix, whose defaults are such that it's
easy to tell if they were overridden)
2) We could attempt to use layout as a default, overriding values as
specified on the command line. Determining which values were
overridden is annoying; I see the following possibilities, all of
which are ugly:
a) parse ac_options ourselves -- probably using the exact same logic
that the autoconf stuff does is too painful (it'd require
duplicating all the information about which options take
arguments) -- but the naive approach would probably suffice:if
we see --foo[=bar], strip [=bar] and say foo was set
b) compare the values with the defaults above, or check to see if the
values start with ${...} -- so that it'd not be valid to specify
an option w/ ${prefix} or ${exec_prefix} at the begining
I'm willing to talk w/ the autoconf folks about adding add'l features,
but I'd be much more leary of suggesting that we require a more recent
version of autoconf for this alone. If anyone has any suggestions (or
if I'm missing a simple way to tell if a variable has been set -- I
tried ${foo+set}, and I know that won't work), I'd love to hear them.
Oh, lastly -- it's easy to fix configure so that overridding prefix
and/or exec prefix can be done within the context of the layouts system.
That doesn't address all the issues, but if folks we like, I can post a
patch which does that.
thanks --
Ed
--srcdir still broken (was Re: new /usr/local/apache2..)
Posted by Sander van Zoest <sa...@covalent.net>.
On Tue, 3 Apr 2001, Marc Slemko wrote:
> Right. And the big question is just how much we have to fit into
> how autoconf does things and how much we sould avoid "the autoconf way".
While we are talking about autoconf, build and dirs. I would like to
point out that AFAIK the --srcdir option is still broken because of
the dependancy of apr-util on apr. The problem is that because you
build with a clean src dir and a seperate obj dir you will have to
specify both dirs to apr-util ./configure instead of just --with-apr.
Because --with-apr is expected to have both the src and generated files.
I tried to work on this somewhat but I am not familiar with autoconf
at all, so I didn't really get far. If anyone feels like taking a
stab at this during ApacheCon feel free. I might try to work on it
some, I will be around so just hunt me down if you need me for
whatever reason.
Cheers,
--
Sander van Zoest [sander@covalent.net]
Covalent Technologies, Inc. http://www.covalent.net/
(415) 536-5218 http://Sander.vanZoest.com/
--srcdir still broken (was Re: new /usr/local/apache2..)
Posted by Sander van Zoest <sa...@covalent.net>.
On Tue, 3 Apr 2001, Marc Slemko wrote:
> Right. And the big question is just how much we have to fit into
> how autoconf does things and how much we sould avoid "the autoconf way".
While we are talking about autoconf, build and dirs. I would like to
point out that AFAIK the --srcdir option is still broken because of
the dependancy of apr-util on apr. The problem is that because you
build with a clean src dir and a seperate obj dir you will have to
specify both dirs to apr-util ./configure instead of just --with-apr.
Because --with-apr is expected to have both the src and generated files.
I tried to work on this somewhat but I am not familiar with autoconf
at all, so I didn't really get far. If anyone feels like taking a
stab at this during ApacheCon feel free. I might try to work on it
some, I will be around so just hunt me down if you need me for
whatever reason.
Cheers,
--
Sander van Zoest [sander@covalent.net]
Covalent Technologies, Inc. http://www.covalent.net/
(415) 536-5218 http://Sander.vanZoest.com/
Re: new /usr/local/apache2 usage, --prefix, and make install
Posted by Marc Slemko <ma...@znep.com>.
On Tue, 3 Apr 2001 ed@apache.org wrote:
> Well, perhaps the problem is that the Apache layout has the prefix
> hardcoded, rather than using the specified prefix or some per-layout
> default prefix (this is generally true of all the layouts). Currently,
> eg. the Apache layout has:
> prefix: /usr/local/apache2
>
> You could start by overriding that value with the value passed in on the
> command line if I did the following:
> ./configure --prefix=/home/ed/apache --layout=Apache
right.
>
> Currently we don't, though -- and that solution won't work without more
> nuance anyway. For example -- RedHat, Darwin, and some other layouts
> explicitly specify complete paths other than prefix -- localstatedir,
> execprefix, iconsdir, etc. How would you handle overrides in that case?
> If a user is doing an install in their home directory, obviously we
> shouldn't expect them to be able to write to /var ...
If the layout is one which does not install all things under a nice
prefix (for some, maybe "prefix: /" would be more appropriate though...),
then the user has to override all the things individually. That's
just the way it works, and is a limitation of that layout. No problem.
Not all layouts are designed to be able to live in their own little
subtree like the Apache one.
> I'm sure we can work out a system, but IMO it needs to be discussed long
> enough to work out such issues. And I don't have all that strong a
Right. And the big question is just how much we have to fit into
how autoconf does things and how much we sould avoid "the autoconf way".
Re: new /usr/local/apache2 usage, --prefix, and make install
Posted by ed...@apache.org.
On Tue, Apr 03, 2001 at 04:09:12PM -0700, Marc Slemko wrote:
> On Tue, 3 Apr 2001 ed@apache.org wrote:
> > I think that prefix should actually be an alternate to a layout. I can
> > see how you might want to override part of a layout with --bindir or
> > --sbindir or ... -- but prefix says to use the standard names as subdirs
> > and base them off the given directory afaict.
>
> Mmm. Not really.
>
> autoconf has a set of (GNUish) directories that you can set such as
> prefix, exec-prefix, bindir, sbindir, libexecdir, datadir, etc. Most of
> them default to being based off prefix or eprefix, by convention.
Well, perhaps the problem is that the Apache layout has the prefix
hardcoded, rather than using the specified prefix or some per-layout
default prefix (this is generally true of all the layouts). Currently,
eg. the Apache layout has:
prefix: /usr/local/apache2
You could start by overriding that value with the value passed in on the
command line if I did the following:
./configure --prefix=/home/ed/apache --layout=Apache
Currently we don't, though -- and that solution won't work without more
nuance anyway. For example -- RedHat, Darwin, and some other layouts
explicitly specify complete paths other than prefix -- localstatedir,
execprefix, iconsdir, etc. How would you handle overrides in that case?
If a user is doing an install in their home directory, obviously we
shouldn't expect them to be able to write to /var ...
I'm sure we can work out a system, but IMO it needs to be discussed long
enough to work out such issues. And I don't have all that strong a
preference as to how it should work, so long as I can use it as an
ordinary user (without editing config.layout) and the docs match the
behavior.
FYI, right now --sysconfdir and --libexecdir had no effect either before
or after. The following directories don't appear to be configurable
(perhaps they should be?) : htdocsdir, iconsdir, cgidir, and logdir.
It'd be nice to fix those things while we're changing how configure
works ...
> We need to have autoconf options for each of the directory/file
> settings. If a layout is specified, they get their defaults from that
> layout, and are then overridden but the command line options. I don't
> know if we can easily do that, or do that and still have configure's help
> message spit out the right info on "defaults".
I'm pretty sure we can do that. I'm willing to work on it, I just want
to be clear on how the options should interact with each other.
cheers --
Ed
Re: new /usr/local/apache2 usage, --prefix, and make install
Posted by Marc Slemko <ma...@znep.com>.
On Tue, 3 Apr 2001 ed@apache.org wrote:
> On Tue, Apr 03, 2001 at 03:05:00PM -0700, Marc Slemko wrote:
> > right, but the thing is that IMHO you should be able to use a layout, and
> > then override parts of it on the command line.
> >
> > that is the way things "should" be, and if they had been that way then
> > this wouldn't break anything. And IMHO, other things are broken (eg. "use
> > GNU layout but install into /foobar") even without the below change.
> >
> > So I think the task is to figure out how to make layouts and autoconf play
> > more nicely, then that will fix this problem too. Figuring this out
> > though... I can take a look, but I try to be as un-autoconf-y a person as
> > possible.
>
> I think that prefix should actually be an alternate to a layout. I can
> see how you might want to override part of a layout with --bindir or
> --sbindir or ... -- but prefix says to use the standard names as subdirs
> and base them off the given directory afaict.
Mmm. Not really.
autoconf has a set of (GNUish) directories that you can set such as
prefix, exec-prefix, bindir, sbindir, libexecdir, datadir, etc. Most of
them default to being based off prefix or eprefix, by convention.
Then we add some more apache-specific ones such as htdocsdir that we need.
Right now, the only things that can be set on the configure command line
are the autoconf ones, and then only if you aren't using a layout. So,
for example, the only way to set a non-default htdocsdir is to use a
layout. That is wrong.
We need to have autoconf options for each of the directory/file
settings. If a layout is specified, they get their defaults from that
layout, and are then overridden but the command line options. I don't
know if we can easily do that, or do that and still have configure's help
message spit out the right info on "defaults".
> If you wanted to allow both prefix and layout, I think the think to do
> would be to prefix all paths in the layout with whatever was given in
> --prefix.
It isn't about prefix vs. layout. Prefix is just one of the dozen things
that can be specified in a layout.
>
> Anyway -- I'd guess that the thing to do in the short term is to revert
> so that if layout isn't specified, Apache isn't used as the default. I
> think the code probably does need reorganization, but it's sort of
> broken right now (unless you're root when you install) ...
Yea. I guess I'll do that. It is somewhat half-assed, but better half an
ass than (a full)|(no) ass.
>
> Btw -- I am willing to work on the autoconf stuff. It's kind of
> annoying to debug 'cause the debug cycles take a while, but other than
> that it's not too bad ...
>
> cheers --
>
> Ed
>
Re: new /usr/local/apache2 usage, --prefix, and make install
Posted by ed...@apache.org.
On Tue, Apr 03, 2001 at 03:05:00PM -0700, Marc Slemko wrote:
> right, but the thing is that IMHO you should be able to use a layout, and
> then override parts of it on the command line.
>
> that is the way things "should" be, and if they had been that way then
> this wouldn't break anything. And IMHO, other things are broken (eg. "use
> GNU layout but install into /foobar") even without the below change.
>
> So I think the task is to figure out how to make layouts and autoconf play
> more nicely, then that will fix this problem too. Figuring this out
> though... I can take a look, but I try to be as un-autoconf-y a person as
> possible.
I think that prefix should actually be an alternate to a layout. I can
see how you might want to override part of a layout with --bindir or
--sbindir or ... -- but prefix says to use the standard names as subdirs
and base them off the given directory afaict.
If you wanted to allow both prefix and layout, I think the think to do
would be to prefix all paths in the layout with whatever was given in
--prefix.
Anyway -- I'd guess that the thing to do in the short term is to revert
so that if layout isn't specified, Apache isn't used as the default. I
think the code probably does need reorganization, but it's sort of
broken right now (unless you're root when you install) ...
Btw -- I am willing to work on the autoconf stuff. It's kind of
annoying to debug 'cause the debug cycles take a while, but other than
that it's not too bad ...
cheers --
Ed
Re: new /usr/local/apache2 usage, --prefix, and make install
Posted by Marc Slemko <ma...@znep.com>.
On 3 Apr 2001, Jeff Trawick wrote:
> Marc Slemko <ma...@znep.com> writes:
>
> > On Tue, 3 Apr 2001, Jeff Trawick wrote:
> >
> > > On Solaris and Tru64 (and maybe more), my --prefix is getting ignored
> > > and instead make install is trying to put stuff in /usr/local/apache2
> > > :(
> > >
> > > looking at it now...
> >
> > ick. yea. sorry about that.
> >
> > Hmm. It is a bit of a mess trying to figure out how autoconf's
> > installation prefixes and stuff like config.layout should play together
> > nicely. Note that I'm pretty sure they didn't work "right" before either,
> > it just wasn't wrong in such a visible way...
>
> I guess this is what broke it:
right, but the thing is that IMHO you should be able to use a layout, and
then override parts of it on the command line.
that is the way things "should" be, and if they had been that way then
this wouldn't break anything. And IMHO, other things are broken (eg. "use
GNU layout but install into /foobar") even without the below change.
So I think the task is to figure out how to make layouts and autoconf play
more nicely, then that will fix this problem too. Figuring this out
though... I can take a look, but I try to be as un-autoconf-y a person as
possible.
>
> if test -z "$LAYOUT"; then
> - htdocsdir='$(prefix)/htdocs'
> - iconsdir='$(prefix)/icons'
> - cgidir='$(prefix)/cgi-bin'
> - logdir='$(prefix)/logs'
> - sysconfdir='${prefix}/conf'
> - libexecdir='${prefix}/modules'
> - layout_name=Apache
> -else
> - APACHE_LAYOUT($srcdir/config.layout, $LAYOUT)
> + LAYOUT="Apache"
> fi
> +APACHE_LAYOUT($srcdir/config.layout, $LAYOUT)
>
> Now we *must* end up using a layout...
>
> --
> Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
Re: new /usr/local/apache2 usage, --prefix, and make install
Posted by Jeff Trawick <tr...@bellsouth.net>.
Marc Slemko <ma...@znep.com> writes:
> On Tue, 3 Apr 2001, Jeff Trawick wrote:
>
> > On Solaris and Tru64 (and maybe more), my --prefix is getting ignored
> > and instead make install is trying to put stuff in /usr/local/apache2
> > :(
> >
> > looking at it now...
>
> ick. yea. sorry about that.
>
> Hmm. It is a bit of a mess trying to figure out how autoconf's
> installation prefixes and stuff like config.layout should play together
> nicely. Note that I'm pretty sure they didn't work "right" before either,
> it just wasn't wrong in such a visible way...
I guess this is what broke it:
if test -z "$LAYOUT"; then
- htdocsdir='$(prefix)/htdocs'
- iconsdir='$(prefix)/icons'
- cgidir='$(prefix)/cgi-bin'
- logdir='$(prefix)/logs'
- sysconfdir='${prefix}/conf'
- libexecdir='${prefix}/modules'
- layout_name=Apache
-else
- APACHE_LAYOUT($srcdir/config.layout, $LAYOUT)
+ LAYOUT="Apache"
fi
+APACHE_LAYOUT($srcdir/config.layout, $LAYOUT)
Now we *must* end up using a layout...
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: new /usr/local/apache2 usage, --prefix, and make install
Posted by Marc Slemko <ma...@znep.com>.
On Tue, 3 Apr 2001, Jeff Trawick wrote:
> On Solaris and Tru64 (and maybe more), my --prefix is getting ignored
> and instead make install is trying to put stuff in /usr/local/apache2
> :(
>
> looking at it now...
ick. yea. sorry about that.
Hmm. It is a bit of a mess trying to figure out how autoconf's
installation prefixes and stuff like config.layout should play together
nicely. Note that I'm pretty sure they didn't work "right" before either,
it just wasn't wrong in such a visible way...