Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Date: Mon, 9 Dec 2002 13:21:27 +0100 (MET)
From: "John D. Garberson" <john.garberson@nexos.com>
Message-Id: <200212091221.NAA07272@ws2.nexos.com>
To: users@httpd.apache.org
Subject: [users@httpd] Confusion with config.layout in moving from Apache
 1.3.X to 2.0.X


This should maybe be reported as a bug, although I guess it isn't one,
strictly speaking, just a confusing change between Versions 1.3 and 2.0.
It may even be that it's documented somewhere in the release, but if so
I missed it.  In any case, I hope this note saves somebody the time it
cost me to find the problem.

If you have a custom directory layout for httpd, you can make your own
config.layout file in both versions, as I'm sure most folks are aware.
We've been using something like this for a while now under 1.3.X:

<Layout foo>
    prefix:        /opt/bar
    exec_prefix:   $prefix
    bindir:        $exec_prefix/bin
    sbindir:       $exec_prefix/sbin
    libexecdir:    $exec_prefix/lib
    mandir:        $exec_prefix/man
    manualdir:     $htdocsdir/manual
    sysconfdir:    /etc$prefix
    datadir:       /var$prefix
    iconsdir:      $datadir/icons
    htdocsdir:     $datadir/htdocs
    cgidir:        $datadir/cgi-bin
    includedir:    $exec_prefix/include
    localstatedir: $datadir
    runtimedir:    $datadir/run
    logfiledir:    $datadir/logs
    proxycachedir: $datadir/proxy
</Layout>

This works just the way you'd think it would: the value defined for prefix
gets substituted for $prefix all the way down the line, as do the variables
derived from it, and everything ends up where you'd like.  You activate
this by calling configure with the option --with-layout=layout_file:foo.
Note the absence of any brackets or parens. in $prefix and other variables!

In Version 2.0, there's similar functionality available.  Here's an example
entry.  

<Layout GNU>
    prefix:        /usr/local
    exec_prefix:   ${prefix}
    bindir:        ${exec_prefix}/bin
    sbindir:       ${exec_prefix}/sbin
    libdir:        ${exec_prefix}/lib
    libexecdir:    ${exec_prefix}/libexec
    mandir:        ${prefix}/man
    sysconfdir:    ${prefix}/etc+
    datadir:       ${prefix}/share+
    installbuilddir: ${datadir}/build
    errordir:      ${datadir}/error
    iconsdir:      ${datadir}/icons
    htdocsdir:     ${datadir}/htdocs
    manualdir:     ${datadir}/manual
    cgidir:        ${datadir}/cgi-bin
    includedir:    ${prefix}/include+
    localstatedir: ${prefix}/var+
    runtimedir:    ${localstatedir}/run
    logfiledir:    ${localstatedir}/log
    proxycachedir: ${localstatedir}/proxy
</Layout>

I naively thought this looked similar enough that I could just add the
additional directory entries which have turned up since 1.3 and use it
with configure as before, although it's now done via

	configure --enable-layout=LAYOUT"

Silly me.  I discovered two problems:

If you specify the LAYOUT parameter incorrectly, you don't get any error
message, configure just continues merrily on its way.  You'll find out later
that you're getting a different layout than you wanted.

The other unfortunate feature of the new set-up is that the variable syntax
in config.layout has changed.  But this is more subtle: notice that the
values are all bracketed in the newer format.  This might be what you'd
expect, if you're thinking in terms of Makefiles, where you'd never get
away with something like $variable.  But if you're used to the scheme under
1.3.X, you'll probably have forgotten all about this in the meantime, you'll
just figure it's going to work as it always has.

And from the looks of it, it does, there's no error message.  But later
on you get a rude surprise.

What happens is that under 2.X the Makefiles for the various subdirectories
get built with the variable definitions just as they appear in
config.layout, that is, with no () or {} inserted, if you don't have them.

Depending on how many modules you're compiling, you may not notice any
problem until you're twenty minutes into the compilation.  In my case, I
started  having failures because the -rpath option to gcc was being called
out of libtool with a relative path instead of an absolute one.  It took
me a good long time to figure out that all the Makefiles had $exec_prefix,
rather than ${exec_prefix} in them, because most of the ones earlier in
the compilation weren't using the definitions, just by chance.

Even your usual expectation that either the ${var} or the $(var) form is
good enough in a Makefile is wrong.  If you replace the $variable lines in
config.layout file with $(variable), you'll get a different error.  But
mercifully, this time it's early in the configure process, not far into
the build, after you've been compiling for a long time.

So, to make a long story short:

1) Check that your layout is being found and respected, if you're defining a
   custom one.

2) Make sure to use the ${ ... } syntax for any variables you introduce
   in your config.layout file.

Hope this saves someone some time and head-scratching.

John


     John Garberson                             nexos ag 
     john.garberson@nexos.com                   Frobenstrasse 66 
                                                CH-4053 Basel, Switzerland
                                                Tel. 41 61 283 55 03
                                                Fax  41 61 283 55 01


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org