On Mon, 20 Mar 2017 19:24:58 +0100 Michał Górny <[email protected]> wrote:
> On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote: > > What makes me wonder more are the proposed solutions: So far the > > only proposals I've seen are either inlining *all* the code or > > moving *all* the code into an eclass. Having a quick look at > > autoconf, it seems to me an intermediate solution would work > > perfectly fine for the above goals/rules: Put main.eblit into an > > eclass. The loading code then would access $FILESDIR only in src_* > > phases. This would likely work better for all parties and would > > allow to focus on better specifying this gray area of PMS instead. > > Don't you find it a bad hypocritical that at the same time you oppose > committing an eclass for a single package and you support committing > an eclass to support half-working hack for a single package? > First, I don't oppose committing an eclass for a single package, I consider it out of scope of eclasses, that's all. But even if I had stronger positions, this one looks like a win-win situation to me: From a code reuse POV, it is an aberration to have packages reinvent eblit include logic, each of them having or having had its different flaws. Still from a code reuse POV, the eclass being able to export functions would reduce ebuild boilerplate code, an eblit eclass could test the presence of eblit code and call default if absent. From a QA POV, eblit functions can die horribly if called outside of src_* phases, ensuring PMS assumptions hold and making everyone happy. And finally, ebuild code for the libc used by 99% of our users, supporting cross-compilers, canadian crosses and what else wouldn't be something I'd call a 'half-working hack'. Alexis.
