Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <029301c13229$f90f4520$93c0b0d0@roweclan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: "Jeff Trawick" <trawick@attglobal.net>, <dev@apr.apache.org>
References: <20010831094754.12546.qmail@icarus.apache.org>
 <m3wv3ke48b.fsf@rdu88-250-106.nc.rr.com>
Subject: Re: cvs commit: apr-util configure.in Makefile.in
Date: Fri, 31 Aug 2001 09:33:57 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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...
>