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

[William Hubbs]

On Sun, Dec 07, 2014 at 08:32:57AM -0500, Rich Freeman wrote:
> On Sun, Dec 7, 2014 at 8:05 AM, Anthony G. Basile
> <basile@××××××××××××××.edu> wrote:
> > 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.
>
> Well, other packages could keep using the eclass.
>
> I think that eclasses tend to get abused in situations like these.  It
> is one thing if you have 300 ebuilds that are all maintained together
> like there are with kde and logic really is shared in common between
> them.
>
> However, this eclass is only used by a few packages, the shared code
> isn't across stuff installed in parallel but across stuff that changes
> over time.  This is done without upstream support for the most part,
> so it becomes a growing collection of workarounds.  When eclasses
> start following different code paths every time a package that uses
> them is versioned, it makes a lot more sense to either version the
> eclass every time or move the code to the ebuild.

This makes sense to me as well, let's work twoard getting rid of
toolchain.eclass.

>
> >
> > 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.
>
> Why do we need a history/comparison of gcc written in shell script?
> Wouldn't a text file or webpage be a better way to document this?
> Wouldn't upstream be the place to document this?
>
> This seems a bit like saying that we don't need the EAPI/PMS guide or
> even PMS itself because anybody can just read the portage source code
> and figure out how it works.
>
> If you need a list of what features are supported in what versions of
> gcc, wouldn't it make more sense to create a wiki page somewhere?

I thinkk this makes more sense as well. Historical reasons don't work
for me by them selves as a reason to justify keeping old code,
especially when it is to support versions of packages that are no longer
really supported upstream.

>
> >>
> >> 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.

Why do you want to keep these outdated and not supported versions of gcc
around? Have you tried building a modern system with gcc-2 or gcc-3? I
haven't but I'm sure it would fail horribly.

> >
> > 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?
>
> Well, that would be in keeping with GLEP 39, which seems to encourage
> everybody to fork each other's packages.  :)
>
> It seems like there is a fundamental disagreement here over the right
> way to refactor all this code.  Honestly, the fact that nobody seems
> to even want to look at the toolchain suggests to me that
> simplification is probably worthwhile.
 
 I tend to agree here too; let's get rid of the old versions of things
 where we can and simplify.

William