You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@ebuilt.com> on 2001/01/29 06:48:59 UTC
build blues
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
Re: build blues
Posted by Jeff Trawick <tr...@bellsouth.net>.
Greg Stein <gs...@lyra.org> writes:
> [ 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.
...
amen (but then I'm guilty of this too from many moons ago :) )
--
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: build blues
Posted by Jeff Trawick <tr...@bellsouth.net>.
Greg Stein <gs...@lyra.org> writes:
> [ 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.
...
amen (but then I'm guilty of this too from many moons ago :) )
--
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: build blues
Posted by Greg Stein <gs...@lyra.org>.
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/
Re: build blues
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 13, 2001 at 02:01:33PM -0800, Roy T. Fielding wrote:
> On Tue, Feb 13, 2001 at 12:58:04AM -0800, Greg Stein wrote:
> > Is it possible to get a partial checkin? That'll let us review pieces as
> > they go (easier to do a small bit, than a huge one), and you won't have to
> > worry about tracking other changes to the build system.
>
> The APR changes include changing the directory name from helpers
> to build and the filename from buildconf to buildconf.sh, which pretty
> much eliminates the commit diff. The nice thing is that it will
> be easy to resurrect the old buildconf if needed.
>
> I could make the changes one-by-one, but it would effectively double
> my work because none of the interim changes would survive.
Understood. Not trying to impose work, but just hoping that your output is
reviewable so that we can see/learn/understand the changes you're making.
> > >...
> > > * make each "top-most" buildconf.sh set up the subdirectory configures
> > > directly with autoheader and autoconf, rather than running each of
> > > their buildconf.sh scripts. This will remove most of the redundant
> > > libtool and configure checks, force the whole tree to be built with a
> > > consistent set of flags, and allow each independent tree's buildconf.sh
> > > to be specialized for standalone builds of that tree.
> >
> > Not sure about this one. Are you talking about APR building a libtool, and
> > having the other pieces just use APR's copy?
>
> Whichever buildconf is called first would create the libtool and
> define BUILD_BASE for use by the others.
APR's buildconf will always be the first, no?
I mean, we couldn't really have APR and APRUTIL using Apache's libtool,
could we?
> > >...
> > > * modify all of the Makefile.in files to use the new @VARS@
> >
> > I'm presuming that your @VARS@ is intended to replace config_vars.mk. Why
> > put it into each Makefile.in? Couldn't the @VARS@ just go into rules.mk.in?
>
> Yes, they go in rules.mk.in, but the $(VARS) and @INCLUDE_RULES@ need to be
> added to the individual Makefile.in files.
I'll have to see this when you're done (don't feel obligated to spend more
time explaining) cuz I still don't understand. If @INCLUDE_RULES@ is
including rules.mk, then each Makefile wouldn't need to have its own @VARS@
since they'd just pick it up from rules.mk.
btw, if you happen to be touching every APR Makefile.in, the INCLUDES stuff
can be collapsed into rules.mk.in. I didn't do it last time cuz it was a
bundle of work already. If you don't mind more pain, then that task is still
waiting :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: build blues
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 13, 2001 at 02:01:33PM -0800, Roy T. Fielding wrote:
> On Tue, Feb 13, 2001 at 12:58:04AM -0800, Greg Stein wrote:
> > Is it possible to get a partial checkin? That'll let us review pieces as
> > they go (easier to do a small bit, than a huge one), and you won't have to
> > worry about tracking other changes to the build system.
>
> The APR changes include changing the directory name from helpers
> to build and the filename from buildconf to buildconf.sh, which pretty
> much eliminates the commit diff. The nice thing is that it will
> be easy to resurrect the old buildconf if needed.
>
> I could make the changes one-by-one, but it would effectively double
> my work because none of the interim changes would survive.
Understood. Not trying to impose work, but just hoping that your output is
reviewable so that we can see/learn/understand the changes you're making.
> > >...
> > > * make each "top-most" buildconf.sh set up the subdirectory configures
> > > directly with autoheader and autoconf, rather than running each of
> > > their buildconf.sh scripts. This will remove most of the redundant
> > > libtool and configure checks, force the whole tree to be built with a
> > > consistent set of flags, and allow each independent tree's buildconf.sh
> > > to be specialized for standalone builds of that tree.
> >
> > Not sure about this one. Are you talking about APR building a libtool, and
> > having the other pieces just use APR's copy?
>
> Whichever buildconf is called first would create the libtool and
> define BUILD_BASE for use by the others.
APR's buildconf will always be the first, no?
I mean, we couldn't really have APR and APRUTIL using Apache's libtool,
could we?
> > >...
> > > * modify all of the Makefile.in files to use the new @VARS@
> >
> > I'm presuming that your @VARS@ is intended to replace config_vars.mk. Why
> > put it into each Makefile.in? Couldn't the @VARS@ just go into rules.mk.in?
>
> Yes, they go in rules.mk.in, but the $(VARS) and @INCLUDE_RULES@ need to be
> added to the individual Makefile.in files.
I'll have to see this when you're done (don't feel obligated to spend more
time explaining) cuz I still don't understand. If @INCLUDE_RULES@ is
including rules.mk, then each Makefile wouldn't need to have its own @VARS@
since they'd just pick it up from rules.mk.
btw, if you happen to be touching every APR Makefile.in, the INCLUDES stuff
can be collapsed into rules.mk.in. I didn't do it last time cuz it was a
bundle of work already. If you don't mind more pain, then that task is still
waiting :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Tue, Feb 13, 2001 at 12:58:04AM -0800, Greg Stein wrote:
> Is it possible to get a partial checkin? That'll let us review pieces as
> they go (easier to do a small bit, than a huge one), and you won't have to
> worry about tracking other changes to the build system.
The APR changes include changing the directory name from helpers
to build and the filename from buildconf to buildconf.sh, which pretty
much eliminates the commit diff. The nice thing is that it will
be easy to resurrect the old buildconf if needed.
I could make the changes one-by-one, but it would effectively double
my work because none of the interim changes would survive.
> >...
> > * make each "top-most" buildconf.sh set up the subdirectory configures
> > directly with autoheader and autoconf, rather than running each of
> > their buildconf.sh scripts. This will remove most of the redundant
> > libtool and configure checks, force the whole tree to be built with a
> > consistent set of flags, and allow each independent tree's buildconf.sh
> > to be specialized for standalone builds of that tree.
>
> Not sure about this one. Are you talking about APR building a libtool, and
> having the other pieces just use APR's copy?
Whichever buildconf is called first would create the libtool and
define BUILD_BASE for use by the others.
> >...
> > * modify all of the Makefile.in files to use the new @VARS@
>
> I'm presuming that your @VARS@ is intended to replace config_vars.mk. Why
> put it into each Makefile.in? Couldn't the @VARS@ just go into rules.mk.in?
Yes, they go in rules.mk.in, but the $(VARS) and @INCLUDE_RULES@ need to be
added to the individual Makefile.in files.
....Roy
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Tue, Feb 13, 2001 at 12:58:04AM -0800, Greg Stein wrote:
> Is it possible to get a partial checkin? That'll let us review pieces as
> they go (easier to do a small bit, than a huge one), and you won't have to
> worry about tracking other changes to the build system.
The APR changes include changing the directory name from helpers
to build and the filename from buildconf to buildconf.sh, which pretty
much eliminates the commit diff. The nice thing is that it will
be easy to resurrect the old buildconf if needed.
I could make the changes one-by-one, but it would effectively double
my work because none of the interim changes would survive.
> >...
> > * make each "top-most" buildconf.sh set up the subdirectory configures
> > directly with autoheader and autoconf, rather than running each of
> > their buildconf.sh scripts. This will remove most of the redundant
> > libtool and configure checks, force the whole tree to be built with a
> > consistent set of flags, and allow each independent tree's buildconf.sh
> > to be specialized for standalone builds of that tree.
>
> Not sure about this one. Are you talking about APR building a libtool, and
> having the other pieces just use APR's copy?
Whichever buildconf is called first would create the libtool and
define BUILD_BASE for use by the others.
> >...
> > * modify all of the Makefile.in files to use the new @VARS@
>
> I'm presuming that your @VARS@ is intended to replace config_vars.mk. Why
> put it into each Makefile.in? Couldn't the @VARS@ just go into rules.mk.in?
Yes, they go in rules.mk.in, but the $(VARS) and @INCLUDE_RULES@ need to be
added to the individual Makefile.in files.
....Roy
Re: build blues
Posted by Greg Stein <gs...@lyra.org>.
Wow! This all sounds great.
Is it possible to get a partial checkin? That'll let us review pieces as
they go (easier to do a small bit, than a huge one), and you won't have to
worry about tracking other changes to the build system.
On Mon, Feb 12, 2001 at 11:30:47PM -0800, Roy T. Fielding wrote:
> Just a heads-up. I am still working on simplifying the build scripts.
> More changes are required for httpd than anything else, though I'd also
> like to streamline, name-protect, and make consistent the apr stuff.
Can we do this in a couple steps?
>...
> * make each "top-most" buildconf.sh set up the subdirectory configures
> directly with autoheader and autoconf, rather than running each of
> their buildconf.sh scripts. This will remove most of the redundant
> libtool and configure checks, force the whole tree to be built with a
> consistent set of flags, and allow each independent tree's buildconf.sh
> to be specialized for standalone builds of that tree.
Not sure about this one. Are you talking about APR building a libtool, and
having the other pieces just use APR's copy?
>...
> * modify all of the Makefile.in files to use the new @VARS@
I'm presuming that your @VARS@ is intended to replace config_vars.mk. Why
put it into each Makefile.in? Couldn't the @VARS@ just go into rules.mk.in?
[ note that Sascha used config_vars.mk to avoid the additional dozens of
substitutions at the end of the configure process. Running all of those
substitutions over all the files takes a good chunk of time. compressing
them down to a single @VARS@ substitution ought to do the trick, too. ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
I've finally got most of my sandbox configure changes checked-in,
but still haven't made the most significant changes:
* APR's configure should be called first to define everything and
generate an apr_make_vars.mk + apr_make_rules.mk in apr/include,
since this will be needed by any program that wants to build
from an installed APR library. We might want to install the
entire apr/build directory. *shrug*
* APR_ADDTO probably shouldn't be exporting variables -- this is
resulting in many repeated parameters on compiles/links.
* APR_PRELOAD should only be called by APR -- other configures
should inline the apr_make_vars.mk (what is now APRVARS) and
override whatever is in their environment. It isn't safe to
build APR clients with a set of compile and link flags
different from those used to build APR.
* Everywhere that we screw with CFLAGS, CPPFLAGS, LDFLAGS, etc.,
needs to be fixed so that we only temporarily modify them for
tests and save ONLY the modifications in EXTRA_*.
* The GNU Makefile standards need to be adhered to in all use
of standard variables and target names -- right now we aren't
even close (CFLAGS is often set with preprocessor defines and
distclean is cleaning too much and extraclean is only defined
within APR). Likewise, the standard names like CFLAGS should
be reserved for environment user-defined flags that can
override any of the ones we create with configure (i.e., they
must appear *after* the other variables on the command lines).
* buildconf needs to be modularized in each distribution
* httpd buildconf needs to be rewritten to eliminate the build.mk
spaghetti -- I've already done this in my sandbox, but it requires
more of the above before I can commit it.
* modify all of the Makefile.in files to use the new $(variables)
* libtoolize --automake --copy
* ./buildconf --disable-libtool [making it an option]
* fix dependencies so that they are created by configure
I have to do a brain swap now and prepare for the Wednesday board meeting,
so if anyone wants to do stuff to configure now is a good time. I won't
lose any work at this point.
....Roy
Re: build blues
Posted by Greg Stein <gs...@lyra.org>.
Wow! This all sounds great.
Is it possible to get a partial checkin? That'll let us review pieces as
they go (easier to do a small bit, than a huge one), and you won't have to
worry about tracking other changes to the build system.
On Mon, Feb 12, 2001 at 11:30:47PM -0800, Roy T. Fielding wrote:
> Just a heads-up. I am still working on simplifying the build scripts.
> More changes are required for httpd than anything else, though I'd also
> like to streamline, name-protect, and make consistent the apr stuff.
Can we do this in a couple steps?
>...
> * make each "top-most" buildconf.sh set up the subdirectory configures
> directly with autoheader and autoconf, rather than running each of
> their buildconf.sh scripts. This will remove most of the redundant
> libtool and configure checks, force the whole tree to be built with a
> consistent set of flags, and allow each independent tree's buildconf.sh
> to be specialized for standalone builds of that tree.
Not sure about this one. Are you talking about APR building a libtool, and
having the other pieces just use APR's copy?
>...
> * modify all of the Makefile.in files to use the new @VARS@
I'm presuming that your @VARS@ is intended to replace config_vars.mk. Why
put it into each Makefile.in? Couldn't the @VARS@ just go into rules.mk.in?
[ note that Sascha used config_vars.mk to avoid the additional dozens of
substitutions at the end of the configure process. Running all of those
substitutions over all the files takes a good chunk of time. compressing
them down to a single @VARS@ substitution ought to do the trick, too. ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
I've finally got most of my sandbox configure changes checked-in,
but still haven't made the most significant changes:
* APR's configure should be called first to define everything and
generate an apr_make_vars.mk + apr_make_rules.mk in apr/include,
since this will be needed by any program that wants to build
from an installed APR library. We might want to install the
entire apr/build directory. *shrug*
* APR_ADDTO probably shouldn't be exporting variables -- this is
resulting in many repeated parameters on compiles/links.
* APR_PRELOAD should only be called by APR -- other configures
should inline the apr_make_vars.mk (what is now APRVARS) and
override whatever is in their environment. It isn't safe to
build APR clients with a set of compile and link flags
different from those used to build APR.
* Everywhere that we screw with CFLAGS, CPPFLAGS, LDFLAGS, etc.,
needs to be fixed so that we only temporarily modify them for
tests and save ONLY the modifications in EXTRA_*.
* The GNU Makefile standards need to be adhered to in all use
of standard variables and target names -- right now we aren't
even close (CFLAGS is often set with preprocessor defines and
distclean is cleaning too much and extraclean is only defined
within APR). Likewise, the standard names like CFLAGS should
be reserved for environment user-defined flags that can
override any of the ones we create with configure (i.e., they
must appear *after* the other variables on the command lines).
* buildconf needs to be modularized in each distribution
* httpd buildconf needs to be rewritten to eliminate the build.mk
spaghetti -- I've already done this in my sandbox, but it requires
more of the above before I can commit it.
* modify all of the Makefile.in files to use the new $(variables)
* libtoolize --automake --copy
* ./buildconf --disable-libtool [making it an option]
* fix dependencies so that they are created by configure
I have to do a brain swap now and prepare for the Wednesday board meeting,
so if anyone wants to do stuff to configure now is a good time. I won't
lose any work at this point.
....Roy
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> We can't use --force. config.guess and config.sub are not stock in our
> tree.
Brilliant. I see it isn't up-to-date with recent autoconf either.
It looks like the only changes we made that are not obsoleted by
the newer autoconf release are the ones for OS/2 emx.
A point of order: committing a change to some other group's standard
file which happens to reside in our tree REQUIRES comment blocks
surrounding the change indicating when and why the change was made.
....Roy
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> We can't use --force. config.guess and config.sub are not stock in our
> tree.
Brilliant. I see it isn't up-to-date with recent autoconf either.
It looks like the only changes we made that are not obsoleted by
the newer autoconf release are the ones for OS/2 emx.
A point of order: committing a change to some other group's standard
file which happens to reside in our tree REQUIRES comment blocks
surrounding the change indicating when and why the change was made.
....Roy
Re: build blues
Posted by rb...@covalent.net.
On Tue, 13 Feb 2001 rbb@covalent.net wrote:
> On Tue, 13 Feb 2001, Greg Stein wrote:
>
> > On Tue, Feb 13, 2001 at 01:46:49PM -0800, Roy T. Fielding wrote:
> > >...
> > > > > * libtoolize --automake --copy --force
> > > > > [the only way we ever want to call libtoolize]
> > > >
> > > > why --automake?
> > >
> > > It is the option libtoolize is given to tell it to shut up because we
> > > are acting like automake (which we are). BTW, the --copy means you
> > > can remove the rm and recopy lines from the tarball builder.
> >
> > Note that we were already using --copy in APR(UTIL).
> >
> > Roy: the --force wasn't added to APR because we had some private copies of
> > two of the libtool files. I'm fine with tossing those if ours were
> > approximately the same, but be careful with that force.
>
> We can't use --force. config.guess and config.sub are not stock in our
> tree.
That's probably a bit cryptic. We don't have stock files, because we have
extra definitions for Darwin, and OS/2.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: build blues
Posted by rb...@covalent.net.
On Tue, 13 Feb 2001 rbb@covalent.net wrote:
> On Tue, 13 Feb 2001, Greg Stein wrote:
>
> > On Tue, Feb 13, 2001 at 01:46:49PM -0800, Roy T. Fielding wrote:
> > >...
> > > > > * libtoolize --automake --copy --force
> > > > > [the only way we ever want to call libtoolize]
> > > >
> > > > why --automake?
> > >
> > > It is the option libtoolize is given to tell it to shut up because we
> > > are acting like automake (which we are). BTW, the --copy means you
> > > can remove the rm and recopy lines from the tarball builder.
> >
> > Note that we were already using --copy in APR(UTIL).
> >
> > Roy: the --force wasn't added to APR because we had some private copies of
> > two of the libtool files. I'm fine with tossing those if ours were
> > approximately the same, but be careful with that force.
>
> We can't use --force. config.guess and config.sub are not stock in our
> tree.
That's probably a bit cryptic. We don't have stock files, because we have
extra definitions for Darwin, and OS/2.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: build blues
Posted by rb...@covalent.net.
On Tue, 13 Feb 2001, Greg Stein wrote:
> On Tue, Feb 13, 2001 at 01:46:49PM -0800, Roy T. Fielding wrote:
> >...
> > > > * libtoolize --automake --copy --force
> > > > [the only way we ever want to call libtoolize]
> > >
> > > why --automake?
> >
> > It is the option libtoolize is given to tell it to shut up because we
> > are acting like automake (which we are). BTW, the --copy means you
> > can remove the rm and recopy lines from the tarball builder.
>
> Note that we were already using --copy in APR(UTIL).
>
> Roy: the --force wasn't added to APR because we had some private copies of
> two of the libtool files. I'm fine with tossing those if ours were
> approximately the same, but be careful with that force.
We can't use --force. config.guess and config.sub are not stock in our
tree.
Ryan
>
> (APRUTIL uses --force because it never had its own copies for better or
> worse)
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: build blues
Posted by rb...@covalent.net.
On Tue, 13 Feb 2001, Greg Stein wrote:
> On Tue, Feb 13, 2001 at 01:46:49PM -0800, Roy T. Fielding wrote:
> >...
> > > > * libtoolize --automake --copy --force
> > > > [the only way we ever want to call libtoolize]
> > >
> > > why --automake?
> >
> > It is the option libtoolize is given to tell it to shut up because we
> > are acting like automake (which we are). BTW, the --copy means you
> > can remove the rm and recopy lines from the tarball builder.
>
> Note that we were already using --copy in APR(UTIL).
>
> Roy: the --force wasn't added to APR because we had some private copies of
> two of the libtool files. I'm fine with tossing those if ours were
> approximately the same, but be careful with that force.
We can't use --force. config.guess and config.sub are not stock in our
tree.
Ryan
>
> (APRUTIL uses --force because it never had its own copies for better or
> worse)
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: build blues
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 13, 2001 at 01:46:49PM -0800, Roy T. Fielding wrote:
>...
> > > * libtoolize --automake --copy --force
> > > [the only way we ever want to call libtoolize]
> >
> > why --automake?
>
> It is the option libtoolize is given to tell it to shut up because we
> are acting like automake (which we are). BTW, the --copy means you
> can remove the rm and recopy lines from the tarball builder.
Note that we were already using --copy in APR(UTIL).
Roy: the --force wasn't added to APR because we had some private copies of
two of the libtool files. I'm fine with tossing those if ours were
approximately the same, but be careful with that force.
(APRUTIL uses --force because it never had its own copies for better or
worse)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: build blues
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 13, 2001 at 01:46:49PM -0800, Roy T. Fielding wrote:
>...
> > > * libtoolize --automake --copy --force
> > > [the only way we ever want to call libtoolize]
> >
> > why --automake?
>
> It is the option libtoolize is given to tell it to shut up because we
> are acting like automake (which we are). BTW, the --copy means you
> can remove the rm and recopy lines from the tarball builder.
Note that we were already using --copy in APR(UTIL).
Roy: the --force wasn't added to APR because we had some private copies of
two of the libtool files. I'm fine with tossing those if ours were
approximately the same, but be careful with that force.
(APRUTIL uses --force because it never had its own copies for better or
worse)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> > * merged apr-conf.m4 and apr_common.m4 into build/acinclude.m4
> > and name-protected all of the macro names
> > -- have not yet name-protected the variables within the macros
>
> Those two files had two very different uses. The first is used for APR
> itself, and is a bunch of macros that no application using APR should need
> or even have to think about. The second is a set of macros that APR
> provides for applications. I would like to see these kept separate,
> because it makes it much easier for application programmers to locate the
> macros they want to use.
Well, that explains why they were created in the first place (would
have been useful to document that in the files), but that certainly
isn't the case for their contents. Both had mixed internal and
external macros. Regardless, the notion that some macros are only
useful for APR and others for its clients just doesn't hold up in
practice -- clients need to know what APR is doing for configure,
which means finding where the macros are defined, which means locating
the macros in one place. Splitting them up by type of macro would
make sense (like apr_pthreads.m4 and hints.m4).
> > * removed some unused macros
>
> such as?
MY_TRY_RUN and another macro which could only be used once as
part of the MM config (and thus was moved inline to configure.in).
> > * libtoolize --automake --copy --force
> > [the only way we ever want to call libtoolize]
>
> why --automake?
It is the option libtoolize is given to tell it to shut up because we
are acting like automake (which we are). BTW, the --copy means you
can remove the rm and recopy lines from the tarball builder.
> > All of the above is done for apr and it is building fine. What I still
> > need to do is
> >
> > * make each "top-most" buildconf.sh set up the subdirectory configures
> > directly with autoheader and autoconf, rather than running each of
> > their buildconf.sh scripts. This will remove most of the redundant
> > libtool and configure checks, force the whole tree to be built with a
> > consistent set of flags, and allow each independent tree's buildconf.sh
> > to be specialized for standalone builds of that tree.
>
> Each subdir will still run stand-alone, correct? There is a part of me
> that dislikes this, because it sounds like it will be possible to
> configure Apache without running APR's buildconf script, which means that
> any bugs in APR's buildconf script are likely to be hidden from a lot of
> the APR developers.
That is a hazard, but buildconf itself should be very small.
I think it is the only way for clients of APR to ensure that their
own builds are consistent (those that don't care can just call
APR's buildconf). Perhaps more importantly, it makes our
build tree behave more like a traditional autoconf setup, which
should reduce some of the hair-pulling experienced with adjusting
configure for portability.
I wish I could understand why libtool is so archaic. Why isn't it
just an autoconf macro that sets variables and defines post-process
macros?
....Roy
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> > * merged apr-conf.m4 and apr_common.m4 into build/acinclude.m4
> > and name-protected all of the macro names
> > -- have not yet name-protected the variables within the macros
>
> Those two files had two very different uses. The first is used for APR
> itself, and is a bunch of macros that no application using APR should need
> or even have to think about. The second is a set of macros that APR
> provides for applications. I would like to see these kept separate,
> because it makes it much easier for application programmers to locate the
> macros they want to use.
Well, that explains why they were created in the first place (would
have been useful to document that in the files), but that certainly
isn't the case for their contents. Both had mixed internal and
external macros. Regardless, the notion that some macros are only
useful for APR and others for its clients just doesn't hold up in
practice -- clients need to know what APR is doing for configure,
which means finding where the macros are defined, which means locating
the macros in one place. Splitting them up by type of macro would
make sense (like apr_pthreads.m4 and hints.m4).
> > * removed some unused macros
>
> such as?
MY_TRY_RUN and another macro which could only be used once as
part of the MM config (and thus was moved inline to configure.in).
> > * libtoolize --automake --copy --force
> > [the only way we ever want to call libtoolize]
>
> why --automake?
It is the option libtoolize is given to tell it to shut up because we
are acting like automake (which we are). BTW, the --copy means you
can remove the rm and recopy lines from the tarball builder.
> > All of the above is done for apr and it is building fine. What I still
> > need to do is
> >
> > * make each "top-most" buildconf.sh set up the subdirectory configures
> > directly with autoheader and autoconf, rather than running each of
> > their buildconf.sh scripts. This will remove most of the redundant
> > libtool and configure checks, force the whole tree to be built with a
> > consistent set of flags, and allow each independent tree's buildconf.sh
> > to be specialized for standalone builds of that tree.
>
> Each subdir will still run stand-alone, correct? There is a part of me
> that dislikes this, because it sounds like it will be possible to
> configure Apache without running APR's buildconf script, which means that
> any bugs in APR's buildconf script are likely to be hidden from a lot of
> the APR developers.
That is a hazard, but buildconf itself should be very small.
I think it is the only way for clients of APR to ensure that their
own builds are consistent (those that don't care can just call
APR's buildconf). Perhaps more importantly, it makes our
build tree behave more like a traditional autoconf setup, which
should reduce some of the hair-pulling experienced with adjusting
configure for portability.
I wish I could understand why libtool is so archaic. Why isn't it
just an autoconf macro that sets variables and defines post-process
macros?
....Roy
Re: build blues
Posted by rb...@covalent.net.
> * merged apr-conf.m4 and apr_common.m4 into build/acinclude.m4
> and name-protected all of the macro names
> -- have not yet name-protected the variables within the macros
Those two files had two very different uses. The first is used for APR
itself, and is a bunch of macros that no application using APR should need
or even have to think about. The second is a set of macros that APR
provides for applications. I would like to see these kept separate,
because it makes it much easier for application programmers to locate the
macros they want to use.
> * removed some unused macros
such as?
> * libtoolize --automake --copy --force
> [the only way we ever want to call libtoolize]
why --automake?
> All of the above is done for apr and it is building fine. What I still
> need to do is
>
> * make each "top-most" buildconf.sh set up the subdirectory configures
> directly with autoheader and autoconf, rather than running each of
> their buildconf.sh scripts. This will remove most of the redundant
> libtool and configure checks, force the whole tree to be built with a
> consistent set of flags, and allow each independent tree's buildconf.sh
> to be specialized for standalone builds of that tree.
Each subdir will still run stand-alone, correct? There is a part of me
that dislikes this, because it sounds like it will be possible to
configure Apache without running APR's buildconf script, which means that
any bugs in APR's buildconf script are likely to be hidden from a lot of
the APR developers.
Other than those few comments, this is awesome.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: build blues
Posted by rb...@covalent.net.
> * merged apr-conf.m4 and apr_common.m4 into build/acinclude.m4
> and name-protected all of the macro names
> -- have not yet name-protected the variables within the macros
Those two files had two very different uses. The first is used for APR
itself, and is a bunch of macros that no application using APR should need
or even have to think about. The second is a set of macros that APR
provides for applications. I would like to see these kept separate,
because it makes it much easier for application programmers to locate the
macros they want to use.
> * removed some unused macros
such as?
> * libtoolize --automake --copy --force
> [the only way we ever want to call libtoolize]
why --automake?
> All of the above is done for apr and it is building fine. What I still
> need to do is
>
> * make each "top-most" buildconf.sh set up the subdirectory configures
> directly with autoheader and autoconf, rather than running each of
> their buildconf.sh scripts. This will remove most of the redundant
> libtool and configure checks, force the whole tree to be built with a
> consistent set of flags, and allow each independent tree's buildconf.sh
> to be specialized for standalone builds of that tree.
Each subdir will still run stand-alone, correct? There is a part of me
that dislikes this, because it sounds like it will be possible to
configure Apache without running APR's buildconf script, which means that
any bugs in APR's buildconf script are likely to be hidden from a lot of
the APR developers.
Other than those few comments, this is awesome.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
Just a heads-up. I am still working on simplifying the build scripts.
More changes are required for httpd than anything else, though I'd also
like to streamline, name-protect, and make consistent the apr stuff.
This is taking a lot longer than expected because the current setup
has coupling among 50 or so different files and I have to backtrace
each of the macros just to figure out what is safe to change.
This is what I have already done in my local copy:
* removed the need for httpd build.mk, build2.mk, bsd_makefile, ...
using the same technique as apr (i.e., rules.mk.in)
* created apr/build (to eventually replace apr/helpers) and
moved all the hard checks into apr.
* standardized on ./buildconf.sh and ./build/
* merged apr-conf.m4 and apr_common.m4 into build/acinclude.m4
and name-protected all of the macro names
-- have not yet name-protected the variables within the macros
* removed some unused macros
* moved the REENTRANCY_FLAGS settings into hints.m4
-- this is actually a bug in the current process
-- we need to define these flags even if apr is --disable-pthreads,
since they affect how errno is interpreted and the current
library relies on apr being consistent with apr's clients.
httpd always defines these flags for the same reason.
* added MKEXPORT, MKDEP, and SCANDOC substitutions to rules.mk.in
so that the Makefile.in files never need to know the paths.
* libtoolize --automake --copy --force
[the only way we ever want to call libtoolize]
All of the above is done for apr and it is building fine. What I still
need to do is
* make each "top-most" buildconf.sh set up the subdirectory configures
directly with autoheader and autoconf, rather than running each of
their buildconf.sh scripts. This will remove most of the redundant
libtool and configure checks, force the whole tree to be built with a
consistent set of flags, and allow each independent tree's buildconf.sh
to be specialized for standalone builds of that tree.
* make apr-util build upon what was generated by apr configure
-- easy, since Greg mostly set it up like this already
* make httpd build upon what was generated by apr-util + apr
* modify all of the Makefile.in files to use the new @VARS@
And, after the rest is done and committed, maybe
* make it possible to build static without libtool
* fix dependencies so that they are created by configure
....Roy
Re: build blues
Posted by rb...@covalent.net.
> > 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.
>
> I'm afraid I don't have much to offer on the "how we got here" front
> (except that we've agreed several times that libtool is the spawn of the
> devil and should be killed :-). But I would certainly be in favour of
> sorting the mess out! And while you are at it, I'm very suspicious of
> dependencies - they really don't seem to work properly...
We got here piecemeal, just like most things. Originally, the buildconf
script was exactly what you proposed Roy, a simple shell script. Then we
decided to make it more complex.
I asked a few weeks ago about removing libtool and autoconf from the tree
for good, assuming that I would get a vast majority and we could clean
this up. Instead, I believe there were 2 votes for removing it, and three
or four for keeping it. I said that was the last time I would raise the
issue.
I tried a while ago to clean up the apache tree, so that it just used the
APR definitions for building, so what you are seeing now is a lot less
cruft than there used to be.
The goal has been for some time (since ApacheCon Orlando), for APR to
provide 99% of the autoconf magic that Apache needs. Obviously, we aren't
there yet. I believe that the goal is basically the following:
Apache's buildconf runs APR's buildconf and APR-util's buildconf first,
then it sets up any other supporting programs, and finally it sets itself
up.
The configure script should also work the same way, APR, then APR-Util,
then other supporting projects, then Apache.
Same goes for make.
I also tried at one point to make APR-util use APR's version of
config.guess, config.sub, libtool, etc. My idea was to make APR-util do
it first, and then get Apache to work the same way. It is still in the
STATUS file, but nobody has gotten to it yet.
As for compiling without libtool, good luck, and more power to you. We
have really bought into libtool with this build process, and I am not sure
that it will be easy to remove.
Finally, as for why APR and Apache sometimes use different words for the
same thing, legacy. I wrote the original APR configure script at about
the same time that Manoj and Rasmus were writing the Apache one. They
copied PHP, I copied something else (don't ask me to remember what, it was
almost two years ago). As we have found these, we have tried to correct
them. Please, feel free to find and fix more of them.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: build blues
Posted by rb...@covalent.net.
> > 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.
>
> I'm afraid I don't have much to offer on the "how we got here" front
> (except that we've agreed several times that libtool is the spawn of the
> devil and should be killed :-). But I would certainly be in favour of
> sorting the mess out! And while you are at it, I'm very suspicious of
> dependencies - they really don't seem to work properly...
We got here piecemeal, just like most things. Originally, the buildconf
script was exactly what you proposed Roy, a simple shell script. Then we
decided to make it more complex.
I asked a few weeks ago about removing libtool and autoconf from the tree
for good, assuming that I would get a vast majority and we could clean
this up. Instead, I believe there were 2 votes for removing it, and three
or four for keeping it. I said that was the last time I would raise the
issue.
I tried a while ago to clean up the apache tree, so that it just used the
APR definitions for building, so what you are seeing now is a lot less
cruft than there used to be.
The goal has been for some time (since ApacheCon Orlando), for APR to
provide 99% of the autoconf magic that Apache needs. Obviously, we aren't
there yet. I believe that the goal is basically the following:
Apache's buildconf runs APR's buildconf and APR-util's buildconf first,
then it sets up any other supporting programs, and finally it sets itself
up.
The configure script should also work the same way, APR, then APR-Util,
then other supporting projects, then Apache.
Same goes for make.
I also tried at one point to make APR-util use APR's version of
config.guess, config.sub, libtool, etc. My idea was to make APR-util do
it first, and then get Apache to work the same way. It is still in the
STATUS file, but nobody has gotten to it yet.
As for compiling without libtool, good luck, and more power to you. We
have really bought into libtool with this build process, and I am not sure
that it will be easy to remove.
Finally, as for why APR and Apache sometimes use different words for the
same thing, legacy. I wrote the original APR configure script at about
the same time that Manoj and Rasmus were writing the Apache one. They
copied PHP, I copied something else (don't ask me to remember what, it was
almost two years ago). As we have found these, we have tried to correct
them. Please, feel free to find and fix more of them.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: build blues
Posted by Ben Laurie <be...@algroup.co.uk>.
"Roy T. Fielding" wrote:
> 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.
I'm afraid I don't have much to offer on the "how we got here" front
(except that we've agreed several times that libtool is the spawn of the
devil and should be killed :-). But I would certainly be in favour of
sorting the mess out! And while you are at it, I'm very suspicious of
dependencies - they really don't seem to work properly...
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: build blues
Posted by Ben Laurie <be...@algroup.co.uk>.
"Roy T. Fielding" wrote:
> 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.
I'm afraid I don't have much to offer on the "how we got here" front
(except that we've agreed several times that libtool is the spawn of the
devil and should be killed :-). But I would certainly be in favour of
sorting the mess out! And while you are at it, I'm very suspicious of
dependencies - they really don't seem to work properly...
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
Just a heads-up. I am still working on simplifying the build scripts.
More changes are required for httpd than anything else, though I'd also
like to streamline, name-protect, and make consistent the apr stuff.
This is taking a lot longer than expected because the current setup
has coupling among 50 or so different files and I have to backtrace
each of the macros just to figure out what is safe to change.
This is what I have already done in my local copy:
* removed the need for httpd build.mk, build2.mk, bsd_makefile, ...
using the same technique as apr (i.e., rules.mk.in)
* created apr/build (to eventually replace apr/helpers) and
moved all the hard checks into apr.
* standardized on ./buildconf.sh and ./build/
* merged apr-conf.m4 and apr_common.m4 into build/acinclude.m4
and name-protected all of the macro names
-- have not yet name-protected the variables within the macros
* removed some unused macros
* moved the REENTRANCY_FLAGS settings into hints.m4
-- this is actually a bug in the current process
-- we need to define these flags even if apr is --disable-pthreads,
since they affect how errno is interpreted and the current
library relies on apr being consistent with apr's clients.
httpd always defines these flags for the same reason.
* added MKEXPORT, MKDEP, and SCANDOC substitutions to rules.mk.in
so that the Makefile.in files never need to know the paths.
* libtoolize --automake --copy --force
[the only way we ever want to call libtoolize]
All of the above is done for apr and it is building fine. What I still
need to do is
* make each "top-most" buildconf.sh set up the subdirectory configures
directly with autoheader and autoconf, rather than running each of
their buildconf.sh scripts. This will remove most of the redundant
libtool and configure checks, force the whole tree to be built with a
consistent set of flags, and allow each independent tree's buildconf.sh
to be specialized for standalone builds of that tree.
* make apr-util build upon what was generated by apr configure
-- easy, since Greg mostly set it up like this already
* make httpd build upon what was generated by apr-util + apr
* modify all of the Makefile.in files to use the new @VARS@
And, after the rest is done and committed, maybe
* make it possible to build static without libtool
* fix dependencies so that they are created by configure
....Roy
Re: build blues
Posted by Greg Stein <gs...@lyra.org>.
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/