Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Date: Tue, 30 Jan 2001 18:41:50 -0800
From: Greg Stein <gstein@lyra.org>
To: "Roy T. Fielding" <fielding@ebuilt.com>, new-httpd@apache.org,
        dev@apr.apache.org
Subject: Re: build blues
Message-ID: <20010130184149.A24695@lyra.org>
Mail-Followup-To: "Roy T. Fielding" <fielding@ebuilt.com>,
	new-httpd@apache.org, dev@apr.apache.org
References: <20010129004859.B1208@waka.ebuilt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <20010129004859.B1208@waka.ebuilt.net>;
 from fielding@ebuilt.com on Mon, Jan 29, 2001 at 12:48:59AM -0500

On Mon, Jan 29, 2001 at 12:48:59AM -0500, Roy T. Fielding wrote:
>...
> 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?

Seems reasonable.

>...
>   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.

libtool is built as part of the configure process. It can't be done during
buildconf.

>   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.

Do it. No idea why it is so complicated. APR and APRUTIL was greatly
simplified.

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

Fix httpd at a minimum. Slight differences from that point can be dealt with
if they're important.

>   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?

It would probably be a bit difficult to arrange, but I bet it could be done.
Use some kind of shell script and set LIBTOOL to it if the real libtool is
disabled. More work than it buys you, I bet.

And note that a platform always has libtool. When we roll, an "ltconfig.sh"
is built (a shell script) and shipped. That bugger creates libtool.

APRUTIL and now APR is the most recent "from scratch" stuff, and (IMO) is
clean and suits our needs. They have a little ways to go, but they're much
more transparent than httpd. APR was a bit "old", but I migrated the APRUTIL
stuff over to it.

I'll also "second" people's point about Apache's configure: it is probably
doing too much, and most can be handled by APR. As a case in point:
APRUTIL's configure is simple, since it is purely based on APR. Yes, Apache
is implicitly a million times more complex than APRUTIL, but I do know that
its configure process can be incredibly simpler.

[ one thing that bugs me to no end is that we define macros with the AC_
  prefix. I see a macro, look it up in the autoconf docs, can't find it,
  then discover we wrote it. blarg. httpd also redoes the threading checks,
  rather than using information gleaned APRVARS. blah blah. lots of mess. ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/