apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: build blues
Date Wed, 14 Feb 2001 02:09:16 GMT
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/

Mime
View raw message