Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Alexis Ballier]

On Mon, 20 Mar 2017 19:24:58 +0100
Michał Górny <mgorny@g.o> 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.