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.
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.
2) Getting this to work with hardened and cross compiling and
musl/uclibc is going to need re-writing far beyond the eclass. The gain
is in my opinion not worth it given what I suggest below:
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.
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?
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.
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
