-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 5 Oct 2008 17:07:40 +0200 > Alexis Ballier <[EMAIL PROTECTED]> wrote: >> Maybe eclasses should die on unknown eapi; the fact is I really hate >> the current way it's done when switching an ebuild to EAPI-2 which >> uses an eclass that exports src_compile; most eclasses don't special >> case eapi-2 yet and we end up running econf twice at best. I fear >> that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll >> support src_configure too) > > There's currently no mechanism for an ebuild or eclass to 'die' in > global scope.
They can call 'die' in global scope. Perhaps it's not the nicest thing to do, but it can be done. > It's something that could be available for future EAPIs without too > much difficulty, though... We discussed this for Exherbo, and decided > upon something like this: > > * Add a new metadata key called BROKENNESS. > > * Any ID with non-empty BROKENNESS is treated as being hard masked and > not unmaskable by the user, in the same way than an unknown EAPI is. > > * Add a function which can only be called in global scope that adds an > item to BROKENNESS. This does *not* prevent further sourcing. > > This one hopefully shouldn't be too hard to implement (Zac?). If people > are running into excessive difficulties with eclasses, it might be > worth doing an EAPI 3 quickly with just this addition... > Considering that they can already call 'die' in global scope I don't see it as being that urgent. - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjo9SsACgkQ/ejvha5XGaOUUQCfRSaJYF3xqWfaLVfE1M5lT0Fk NDcAnikfPOu/6nnBZIXuKbUXptNIPyOP =Lpc7 -----END PGP SIGNATURE-----
