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