On Thu, 3 Sep 2020 14:49:25 +0100 Michael 'veremitz' Everitt <gen...@veremit.xyz> wrote:
> I know this is a much more onerous "solution" but I thought I would throw > it out there, and see if any other interested parties (eg. kent\n and > potentially graaff) may be able to share their thoughts.. Actually, the more I think about it, there are 2 major reasons not to do this: 1. Its a premature abstraction that centralises a point of failure, and so any defects in this POF scale to all places, producing even more places where changing one eclass requires regenerating the md5 cache for the whole tree, and makes it *harder* to specify logic that only occurs in one languages ecosystem. 2. What happens if two eclasses inherit this shared eclass, and declares "which variables do I look into" via other variables that define its API?, and then, one ebuild consumes *both*. Presently, inheriting two eclasses, one for python, one for lua, and taping together how they build inside the ebuild itself seems viable. But if the logic is shoehorned into a common eclass, that will likely go really fucking pear shaped, unless done with a very fucked up/complicated API. I don't think this is worth it.
pgpDDuuC_8O8A.pgp
Description: OpenPGP digital signature
