apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject build blues
Date Mon, 29 Jan 2001 05:48:59 GMT
I am getting really frustrated by the build system (again).
I don't understand why it is so complicated, and I'm afraid that
if I try to simplify it the whole thing will fall apart.
This isn't because of autoconf -- I've seen far more complex
packages use autoconf without any of these complications.
I think we are just doing things in the wrong order.

Right now we do something like six separate builds from the top-level
httpd, and each one is duplicating most of the autoconf checks for
header files, variables and libtool.  That sucks.

So, before I go and do something that I'll later regret, why can't we
do the following: make apr the center of the build universe, build it
first (without any dependencies on the higher-level code that will make
use of it), then build apr-util in such a way that it picks up all of
the build files generated by apr and only adds its own specific stuff,
and finally build httpd using all of the files generated by apr-util
and apr?

I've looked at it and run into the following unknowns:

  1) libtool wants to be built at the top level of the source tree,
     whatever that means.  I think the answer is to only build libtool
     once, within buildconf.  That means httpd and each independent
     srclib has its own buildconf, which is only run when the user
     intends that directory to be their "top".  *shrug*
     No idea if that would work.  No idea why libtool is so anal.

  2) httpd buildconf is spaghetti -- it calls make in order to load
     build.mk which then execs a bunch of shell commands and finally
     make build2.mk to call another set of shell commands.

     WTF is that all about?

     We don't need no stinkin' dependency checking for the buildconf
     process, so all that make does here is make it impossible to follow
     the sequence of commands in linear order.  Our buildconf should stay
     within the first shell script, do the checks, generate whatever
     dynamically generated.in files are needed, and simply run autoheader
     and autoconf on the whole tree.

     Worse, apr buildconf uses the same names to do something almost
     but not quite the same as httpd buildconf.  Likewise for apr-util.

  3) libtool again.  If a platform does not have libtool, why do we
     insist on using it?  Why can't we just define the appropriate
     symbols to be empty strings and let the code be built as
     static libraries?  Personally, I never need shared libraries
     (they are nothing but a performance loss for anything but
     binary builds and large ISPs that have customer-specific modules).
     I'd like to be able to say

         ./buildconf --disable-libtool

     and have it all work out.  Am I dreaming?

Anyway, in order to get the OPTIM thing working consistently, we
need to have a consistent build process across the whole tree
(or at least for those pieces of software which we maintain).
Right now I have zero confidence that Apache 2.0 builds consistently
on our own development platforms, let alone those out in the wild.

I am willing to throw more time at fixing this stuff, but I need
to understand how we got to this point.  I went back and read
the mail archives surrounding the decision to drop automake
and go with this stuff, but my guess is that the existing scripts
simply weren't meant to be used in a multiheaded tree, and a lot
of stuff has been added willy-nilly just to keep it working.

....Roy

Mime
View raw message