Dnia 2014-12-07, o godz. 08:05:59 "Anthony G. Basile" <bas...@opensource.dyc.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
pgpKvo5EUZxOY.pgp
Description: OpenPGP digital signature
