| 1 |
On 12/07/14 05:37, Michał Górny wrote: |
| 2 |
> |
| 3 |
> If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd |
| 4 |
> appreciate any bug reports, except for those covering things i've |
| 5 |
> already listed as missing :). Any further comments will be very helpful |
| 6 |
> in deciding on the way forward. |
| 7 |
|
| 8 |
Removing the eclass is a bad idea: |
| 9 |
|
| 10 |
0) This reduces code reusability. The eclass is used by |
| 11 |
sys-devel/kgcc64 in the tree and (at least) the hardened-dev::musl |
| 12 |
overlay outside. |
| 13 |
|
| 14 |
1) Those version specific conditionals that you don't like give a |
| 15 |
history/comparison of gcc versions. It is not cruft. It encodes what |
| 16 |
versions allow what features. Moving to the ebuilds makes this history |
| 17 |
much harder to read. Think of a diff -Naur when producing a patch. I |
| 18 |
like the current eclass approach. |
| 19 |
|
| 20 |
2) Getting this to work with hardened and cross compiling and |
| 21 |
musl/uclibc is going to need re-writing far beyond the eclass. The gain |
| 22 |
is in my opinion not worth it given what I suggest below: |
| 23 |
|
| 24 |
> |
| 25 |
> If there is a real interest in my fork, I will probably move it to gx86 |
| 26 |
> as sys-devel/gcc-mgorny. |
| 27 |
|
| 28 |
I don't think we should proceed this way. The way I'd like to proceed |
| 29 |
is to introduce a new toolchain-r1.eclass which addresses at least your |
| 30 |
QA issues below. If I understood Ryan's plan with the eclass, it was to |
| 31 |
simply refactor the phase functions to modernize things but keep |
| 32 |
backwards compat. When toolchain-r1.eclass is mature, then we switch |
| 33 |
the inherit. I'd like to keep gcc-2* and gcc-3* around. We could |
| 34 |
consider cleaning up those ebuilds to work with EAPI=4 or 5 with the new |
| 35 |
eclass or just leave them with the old eclass. |
| 36 |
|
| 37 |
Also, no to the name sys-devel/gcc-mgorny. I very much appreciate the |
| 38 |
excellent hard work you've done on eclasses, but the reason this is |
| 39 |
happening is because of patches that toolchain lead is not accepting. |
| 40 |
Anyhow, most of the work with gcc (in my opinion) is with the patches |
| 41 |
against gcc itself which are housed in ~vapier, ~rhill and ~zorry. When |
| 42 |
you don't accept my patches to gcc-mgorny, shall I add gcc-basile to the |
| 43 |
tree? |
| 44 |
|
| 45 |
I will also be happy to work on replacing |
| 46 |
> the new versions of original sys-devel/gcc completely. With QA process |
| 47 |
> against toolchain.eclass if necessary. |
| 48 |
> |
| 49 |
|
| 50 |
Let's get the list of QA issues so I at least can work towards a |
| 51 |
toolchain-r1.eclass if you're not interested in going that way. Also, I |
| 52 |
take the QA issues seriously, but threatening a QA intervention against |
| 53 |
toolchain and then acting by forking is heavy handed. QA actions |
| 54 |
against the current codebase is understandable. |
| 55 |
|
| 56 |
So to sum, I'd like to see the QA issues (and others) address in the |
| 57 |
current approache and toolchain.eclass. Since we can make mistakes and |
| 58 |
since toolchain is fragile, I suggest a toolchain-r1.eclass where we can |
| 59 |
test (just change the inheritance in gcc ebuilds for testing) and |
| 60 |
finally, when we're happy, do the switcheroo. |
| 61 |
|
| 62 |
|
| 63 |
-- |
| 64 |
Anthony G. Basile, Ph. D. |
| 65 |
Chair of Information Technology |
| 66 |
D'Youville College |
| 67 |
Buffalo, NY 14201 |
| 68 |
(716) 829-8197 |
Archives