Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing

[Michał Górny]

Dnia 2014-12-07, o godz. 08:05:59
"Anthony G. Basile" <basile@××××××××××××××.edu> napisał(a):

> On 12/07/14 05:37, Michał Górny wrote:
> >
> > If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd
> > appreciate any bug reports, except for those covering things i've
> > already listed as missing :). Any further comments will be very helpful
> > in deciding on the way forward.
>
> Removing the eclass is a bad idea:
>
> 0) This reduces code reusability.  The eclass is used by
> sys-devel/kgcc64 in the tree and (at least) the hardened-dev::musl
> overlay outside.

kgcc64 is no longer necessary given --enable-targets in gcc.
And the eclass code is not really reusable, it's too damn complex
and too tightly-coupled to be.

> 1) Those version specific conditionals that you don't like give a
> history/comparison of gcc versions.  It is not cruft.  It encodes what
> versions allow what features.  Moving to the ebuilds makes this history
> much harder to read.  Think of a diff -Naur when producing a patch.  I
> like the current eclass approach.

And why should I care about what gcc3.4 had? I'd rather have a properly
working gcc4.[89] ebuild I could understand. Without code that no
longer does anything but you can't see it because you are blinded by
stupid conditionals and eclass complexity.

> > If there is a real interest in my fork, I will probably move it to gx86
> > as sys-devel/gcc-mgorny.
>
> I don't think we should proceed this way.  The way I'd like to proceed
> is to introduce a new toolchain-r1.eclass which addresses at least your
> QA issues below.  If I understood Ryan's plan with the eclass, it was to
> simply refactor the phase functions to modernize things but keep
> backwards compat.  When toolchain-r1.eclass is mature, then we switch
> the inherit.  I'd like to keep gcc-2* and gcc-3* around.  We could
> consider cleaning up those ebuilds to work with EAPI=4 or 5 with the new
> eclass or just leave them with the old eclass.

And we create a new eclass every time the old one proves being
unmaintainable to the point nobody is willing to work on it? That's
a workaround, not a solution to the problem.

> Also, no to the name sys-devel/gcc-mgorny.  I very much appreciate the
> excellent hard work you've done on eclasses, but the reason this is
> happening is because of patches that toolchain lead is not accepting.
> Anyhow, most of the work with gcc (in my opinion) is with the patches
> against gcc itself which are housed in ~vapier, ~rhill and ~zorry.  When
> you don't accept my patches to gcc-mgorny, shall I add gcc-basile to the
> tree?

Naming is the least of the problems. As far as I am concerned, it can
be 'gcc-sanity-restored' or whatever.

> > I will also be happy to work on replacing
> > the new versions of original sys-devel/gcc completely. With QA process
> > against toolchain.eclass if necessary.
> >
>
> Let's get the list of QA issues so I at least can work towards a
> toolchain-r1.eclass if you're not interested in going that way.  Also, I
> take the QA issues seriously, but threatening a QA intervention against
> toolchain and then acting by forking is heavy handed.  QA actions
> against the current codebase is understandable.
>
> So to sum, I'd like to see the QA issues (and others) address in the
> current approache and toolchain.eclass.  Since we can make mistakes and
> since toolchain is fragile, I suggest a toolchain-r1.eclass where we can
> test (just change the inheritance in gcc ebuilds for testing) and
> finally, when we're happy, do the switcheroo.

First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to
understand and track. If you can remove it and make gcc into proper
ebuilds that can get revision-level changes, we can discuss.

-- 
Best regards,
Michał Górny