apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: apr-util configure.in Makefile.in
Date Fri, 31 Aug 2001 14:33:57 GMT
Jeff,

  this will become a problem on Win32 as well, and it's pretty fragile.

  What if we institute a two-pass clean?  Don't eliminate any dependencies on the
first go, and the distclean target can then mop up the obvious (.mk targets, generated
.h files, etc.)  I think this would be safer, all the way around.  Trying to toggle
build orders by model will just get messier and messier.

Bill

----- Original Message ----- 
From: "Jeff Trawick" <trawick@attglobal.net>
To: <dev@apr.apache.org>
Cc: <apr-util-cvs@apache.org>
Sent: Friday, August 31, 2001 8:41 AM
Subject: Re: cvs commit: apr-util configure.in Makefile.in


> dreid@apache.org writes:
> 
> > dreid       01/08/31 02:47:53
> > 
> >   Modified:    srclib   Makefile.in
> >                .        configure.in Makefile.in
> >   Log:
> >   With my normal sense of missing the boat :)
> >   
> >   This gets the build working on BeOS again :)  Apologies for the delay :(
> >   
> >   Jeff changed the order of apr-util and apr to solve a "cleaning" issue but
> >   that makes me uncomfortable as apr-util is dependant on apr, so if we clean
> >   apr-util we shouldn't be altering anything in apr.  If I decide to rebuild
> >   apr-util then apr should still be buildable.  Sorry Jeff but I think we need
> >   a different solution :(
> 
> Cleaning is extremely important :)  It is mandatory to get a proper build
> anywhere.  (Okay, the only real reason I care is that it keeps a
> stream of e-mails from hitting my inbox.)
> 
> I think that the issue is that on BeOS apr-util is dependent on apr in
> a way that it isn't anywhere else (i.e., apr libraries have to be
> build before apr-util libraries only on BeOS).
> 
> If this can't be avoided due to some BeOS limitation then the makefiles
> have to become a little more complicated so that 
> 
> 1) there is a different order for make vs. make *clean
> 
> or
> 
> 2) apr-util copies apr's rules.mk to one of its own directories to
>    remove the *clean dependency on apr (I don't know if this is the
>    only apr file in this category)
> 
>    apr-util's makefiles would include its copy, apr-util's makefiles
>    would remove it during *clean
> 
> Actually, #2 seems pretty simple.
> 
> Comments anyone?
> 
> -- 
> Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
>        http://www.geocities.com/SiliconValley/Park/9289/
>              Born in Roswell... married an alien...
> 



Mime
View raw message