I'll even top post this one :P Take it back to the thread flameeyes
started about this originally pretty please, with sugar on top.
On Jul 9, 2005, at 9:10 AM, Martin Schlemmer wrote:
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
--
gentoo-dev@gentoo.org mailing list
