On Friday 17 June 2005 04:32, Aron Griffis wrote: > Before working on a solution to the problem, could we get a more > complete list of the tools in question? This has come up before but > the list seems to always end with "etc etc" ;-) Because I don't really know how many applications are available in different flavours.. so that's why we can use eselect so that it can be adapted "on the fly".
> Unless I misunderstand you, I don't like this at all. It means that > when an ebuild calls "grep" it doesn't have any idea what the > supported flags are. Well about grep we have no misunderstanding... grep is GNU grep also on the BSD. And actually it has no idea currently about that on G/FBSD or G/OSX.. we condition this using aliases, but the long-term goal is to avoid this. > So far we've been free to exploit GNU extensions (aka > reasonable functionality) in ebuilds. I'd hate to see that go away. Never said it must go away, actually there's no way that it can go away completely but.. .we can ask *explicitely* for GNU tools in those cases (using gsed instead of sed just as an example, or gfind instead of find). > What scripts are you thinking of in this statement? Sometimes > ./configure checks, not always, and AFAIK most other scripts don't > check. Most of them checks for GNU tools when they need them, for example there are a few ./configure which, knowing they need GNU make, in a system where make is BSD and gmake is GNU, launching "make" then exec gmake to do the actual work. > See, it's this "sed stuff is as compatible as possible" thing I don't > like. You're talking about writing to a standard instead of an > implementation. That works for a couple of well-defined compiled > languages, but I don't think it's going to work for shell scripting > (ebuilds), especially when the reality is that we'd be writing to half > a dozen different implementations instead of a standard at all... See above: when we need GNU sed, we can use gsed. > I don't think that switching to g-prefixed commands for GNU utilities > is a good answer. We aren't going to be able to push that upstream, > which means maintaining a lot of patches ourselves. Upstream usually already have this fixed for BSD system for example. I haven't had too much trouble with that before on G/FBSD, for example the only autotool-created makefile which failed on BSD make was gawk, and that just because it used $(RM) var directly; most ./configure scripts checks for rm and creates $(RM) var themselves when make != gmake. > What you're suggesting would cause a lot of pain for the majority of > Gentoo develpers, i.e. the ones running GNU/Linux. As we are now, on G/FBSD we have anyway quite all the GNU utilities (but for example we don't need tar and about find we can use the BSD's one with ebuilds. Anyway, as I already had done, I'm here to fix in case something is using the wrong way... after a couple of examples this can be quite simple as for the old gnu-find dependent ebuilds which are now fixed. -- Diego "Flameeyes" Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)
pgpu8TEdWaiQA.pgp
Description: PGP signature
