On 03/11/2012 07:03 PM, Brian Harring wrote: > Pragmatic reality, the eapi function actually would work fine. As > pointed out elsewhere, bash parses as it goes- which isn't going to > change. > > If someone invokes 'eapi happy-meal' and it's not supported, > the sourcing is stopped immediately, cache gets -happy-meal for the > EAPI, and the pm continues to ignore the ebuild till either the > ebuilds mtime changes (which case it redoes the metadata regen) or the > PM now supports that EAPI, and... you guessed it, redoes the metadata > regen. The cache behaviour is basically the same regardless of the > EAPI mechanism. > > Now, this isn't to say everyone views the function as *optimal*. > People can argue about that as much as they'd like. > > The point however is that it *would* work. Anyone claiming > fragility/otherwise needs to put forth actual code examples.
Suppose that EAPI 5 requires bash-5. There may be bash-5 syntax in the ebuild prior to your eapi() function call, causing a fatal syntax error. >> Anyway, lets focus on our main goal, which is to decide on a way to >> obtain the EAPI _without_ sourcing the ebuild. > > Nitpicking, but the point needs be made; this is *your* requirement. > The requirement is to be able to deploy new globals/bash > requirements/whatever. Well, I think most people would tend to accept my requirement, and that it falls within the realm of common-sense if avoiding unnecessary complexity is one of our goals. -- Thanks, Zac
