From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <7f2514d753cc3328b18b3235f219bcbe@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] impressive
Date: Mon,  8 May 2006 21:20:42 -0500
From: quanstro@quanstro.net
In-Reply-To: <100B50D3-71C0-4E24-A041-EFEFCF14214F@telus.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 4f999ebc-ead1-11e9-9d60-3106f5b1d025

been there.  done that.  the problem is that you end up wasting one person's time
with build-related issues.  not many people understand make very well.
and parameterizing make variables -- which i was attempting to allude to ---
does not help matters.  

when i was knee deep in this dreck, i don't remember gnu make having target-local
variables.  i had to do it through other subterfuge, including VPATH and friends.

- erik

> I just did it over the last two weeks.  Cross compiles 2.5 platfroms  
> (SPUs are strange), with tests and debug targets.  Not too bad if you  
> are willing to let *one* person hold the per-directory included- 
> makefiles in order.  It makes a huge difference (both things, the  
> full dependency tree, and the one person thing).
> But the code is a little rude - your world winds up with too many  
> parameterized make variables: $($(TARGETOS)$(DIR)BUILDDIR).  And you  
> have to use GNU make's target-local variables to remember that state.
> It ain't pretty.
> 
> Is there a better solution?
> 
> Paul
>