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/
