On Thursday 14 May 2009 23:53:37 Ciaran McCreesh wrote: > On Thu, 14 May 2009 16:49:09 -0500 > > William Hubbs <willi...@gentoo.org> wrote: > > The second solution seems to be the better one because it does not go > > against standards. For example, we see extentions like .c, .py and > > .pl, instead of .c-43, .py-25 and .pl-58. There are ways within the > > languages to tell which version of the compiler is compiling them as > > needed. So, If we say that, EAPI 4, for example, requires bash-4.0, > > Isn't there a way the PM could find out which version of bash is being > > run, compare that to the EAPI, then take appropriate action? > > It can't, because it doesn't know the EAPI until it's sourced the thing > using bash. Using things like += in global scope will break older bash > versions to the point that they can't reliably extract EAPI.
Trying to pull a Goebbels, eh? As I've said a few times you don't have to do something as complex as sourcing it. In most cases you might get lucky and have some form of caching or pre- parsed data available, so you don't even have to care. And in the other cases, assuming that we're talking about current ebuilds which are shell-ish and either define EAPI explicitly or can be assumed to be EAPI0 you can search with a simple regexp. That's so funky that it even works! So if you were a lazy Unix coder you'd just restrict the current rules a bit so that there's only one line starting with EAPI= allowed (or maybe you just take the first or last one, but that's annoying) and if no such line matches you can safely assume EAPI0 Maybe you're very lazy, so you explicitly forbid eclasses from setting or changing EAPI. That also avoids weird effects that make you lose lots of time for debugging because you didn't think about what would happen if foo.eclass set EAPI="3.14" and bar.eclass inherited later set EAPI="1" ... And magically you haven't really changed current behaviour, can get the EAPI without sourcing it and you can be lazy once more. Isn't it great?
