On Sat, 2005-07-09 at 15:11 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 09 July 2005 15:05, Martin Schlemmer wrote:
> > Ditto - point being, is that if you want the agony of per-ebuild hacks,
> > be my guest, but do not expect the rest to hold your hand.
> It's not a matter of per-ebuild hack.
> Let me explain for example:
> 
> for a bit of time we had make -> gmake alias on g/fbsd profiles, but emake 
> still called plain "make" (bsdmake).
> That was fine for most of the cases, gawk was the first one failing because it 
> uess $(RM) which on gmake is an internal but it's not in other makes. The 
> "good" solution was to fix the configure.in (or .ac i don't remember) to make 
> sure that RM variable was set. That was discarded and we needed to let emake 
> call gmake.
> 
> The problem of make/gmake is minimal, just a few corner cases, but I don't 
> really like have to use alias make='gmake' in profiles.

Could do a make wrapper similar to the emake one, that just
stips /usr/$(get_libdir)/portage/bin from PATH, and then run $MAKE.
Then bsd will only need to add MAKE=gmake to its profile, and change it
to MAKE=make or whatever for the bsd only stuff ?  (as I assume you
already have to do that for emake ...)

Anyhow, just a suggestion.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa