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 > <[email protected]> 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
signature.asc
Description: Digital signature
