Re: build blues
Finished another wave of build changes. I still have the following left to do: * fix places where $(top_builddir) is being misused -- that variable is assumed by libtool to be the location of libtool/shlibtool. * 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* * modify all of the Makefile.in files to use the new $(variables) and INCLUDE_RULES instead of the bsd_makefile hack. * 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). * apr-util should be using apr's libtool and PrintPath, as should any distro that is dependent on apr. * move the rest of the non-standard build files to the build directory. * ./buildconf --disable-libtool[making it an option] * fix dependencies so that they are created by configure Roy
Re: build blues
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
> 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
On Tue, 13 Feb 2001 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: build blues
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 [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: build blues
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
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
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
> >* 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
>* 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 [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: build blues
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
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
Greg Stein <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: build blues
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
> > 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 [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: build blues
"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
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