Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On 12/09/2014 11:21, Michał Górny wrote: Dnia 2014-12-08, o godz. 09:56:11 Alexis Ballier aball...@gentoo.org napisał(a): On Sun, 7 Dec 2014 11:37:57 +0100 Michał Górny mgo...@gentoo.org wrote: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. Could you please elaborate on this ? How and why this broke, what is wrong in glibc, what would be a sane crossdev alternative and how crossdev is not. 1. eblits are broken in glibc. Another case of incorrect interpretation of code sharing with love for breaking stable ebuilds. Plus I'd love to add multilib flags to it but we'll likely doing that to main glibc as well soon, if eblits don't get into our way. Originally, eblits were supposed to be ways of sharing common blocks of code between ebuilds in a specific package, but not anything that would warrant a new eclass (local package eclasses, kinda?). They never really took off for reasons lost to time. I use them in mips-sources, but version them so that if I change an eblit, it gets a new version and the old version is removed only when there are no more consumers. The idea of eblits itself isn't bad, but probably could use some re-thinking and/or re-implementation. Especially if a decent amount of kilobytes can be shaved off a given package's directory. 2. crossdev is broken because it creates semi-random, unmaintained ebuilds in randomly chosen overlay, those ebuilds relying on toolchain.eclass behavior. I would argue this isn't necessarily broken. crossdev produces working cross-toolchains and is a valuable tool for anyone running multiple arches, especially slower arches. How it produces said working cross-toolchains is an implementation detail. Don't be so hasty as to throw the baby out with the bathwater. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On 2014-12-07 11:37, Michał Górny wrote: Hello, developers and users. As some of you know, the toolchain packages in Gentoo suffer from lack-of-sanity issues and their maintainers are completely unwilling to improve things. I have finally decided to start working on a fork of the sys-devel/gcc ebuilds, and I have some bits ready for initial testing in 'mgorny' repo, so I would like to know your opinion. Before you start, the shortcomings are: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. 2. No gcj support. Since the ebuild has been forked out of toolchain.eclass, and the gcj support suffers a lot of issues there, I decided there's no point in copying the code. Not sure if anybody actually uses it, and if it is actually useful for anything but will probably get reintroduced one day [above 'if' applies too]. 3. No bootstrapping, fallbacks and possible some other random feature support. The goal was pretty much to get gcc compiling first, and avoid awful lot of effort if things prove to have no future. 4. Hardened is not tested. I think I have copied all the needed code and fixed some stuff but I have no clue if it still works ;). Now, the major changes are: 1. Most of the insanity removed. No more toolchain.eclass. The ebuild has just the code for the current gcc version. You can read it and know what it does, you don't have to parse a few dozen version conditionals, runtime conditionals and random crap code that doesn't do anything in some gcc versions. In fact, I think I removed most of the no-op code. And now you can actually change something in the ebuild without caring for gcc3.4, or without breaking stuff for stable ebuilds. 2. USE flags are supposed to work. I've replaced the cases when they were silently ignored with REQUIRED_USE. I've also removed the silent removals when they didn't work -- so if your current toolchain is broken, things may actually fail instead of giving your different gcc than you wanted. Probably deserves explanatory pkg_pretend() at some point, with messages like 'disable USE=-foo because your toolchain is broken'. 3. Things simplified where they could have been simplified. For example, I removed the big gcc executable moving function and replaced it with --enable-version-specific-runtime-libs. It was enabled in toolchain.eclass with a comment 'If we enable it on non-Darwin we screw up the behaviour this eclass relies on.' So yep, precious cargo cult -- why enable something that would require you to remove your useless complex function?! 4. Added gx86-multilib love. Now you have abi_* flags to control the compiler runtime. Of course, since gcc is a pile of random modules not fit for one another it has different code for different targets. In particular, on mips you can't do two ABIs -- either single one (non-multilib) or all three of them (--enable-multilib). 5. Added multilib gcc wrappers. Long story short, multilib gcc now shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it doesn't screw up your system! Of course, the final implementation may differ since it's an early idea but it works. Now distcc happily builds stuff for your x86 clients. 6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen rather than silently skipping doc build when it's not installed... 7. Disabled bootstrap by default (and in fact completely for now). It is not *that* useful, and means time savings (and distcc support): Thu Nov 6 20:39:31 2014 sys-devel/gcc-4.9.2 merge time: 1 hour, 56 minutes and 43 seconds. Sun Dec 7 10:46:08 2014 sys-devel/gcc-4.9.2-r100 merge time: 34 minutes and 55 seconds. 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. If there is a real interest in my fork, I will probably move it to gx86 as sys-devel/gcc-mgorny. 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. Thanks, I've tried this on ~amd64. It builds in 10 minutes (wow!), tested to build some core stuff with it: kernel 3.17, glibc, coreutils, openssl, ssh... All seems to work fine. I'll try to recompile the whole machine with it. After emerge, there are these notices: * QA Notice: command not found: * * /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 3110: pax-mark: command not found * /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 3111: pax-mark: command not found # emerge -pvq gcc [ebuild R ] sys-devel/gcc-4.9.2-r100 USE=cxx fortran nls nptl openmp pie sanitize (-altivec) -doc (-fixed-point) -go -graphite (-hardened) (-libssp) -objc -objc++
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
Dnia 2014-12-09, o godz. 14:23:21 Tomas Mozes tomas.mo...@shmu.sk napisał(a): On 2014-12-07 11:37, Michał Górny wrote: Hello, developers and users. As some of you know, the toolchain packages in Gentoo suffer from lack-of-sanity issues and their maintainers are completely unwilling to improve things. I have finally decided to start working on a fork of the sys-devel/gcc ebuilds, and I have some bits ready for initial testing in 'mgorny' repo, so I would like to know your opinion. Before you start, the shortcomings are: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. 2. No gcj support. Since the ebuild has been forked out of toolchain.eclass, and the gcj support suffers a lot of issues there, I decided there's no point in copying the code. Not sure if anybody actually uses it, and if it is actually useful for anything but will probably get reintroduced one day [above 'if' applies too]. 3. No bootstrapping, fallbacks and possible some other random feature support. The goal was pretty much to get gcc compiling first, and avoid awful lot of effort if things prove to have no future. 4. Hardened is not tested. I think I have copied all the needed code and fixed some stuff but I have no clue if it still works ;). Now, the major changes are: 1. Most of the insanity removed. No more toolchain.eclass. The ebuild has just the code for the current gcc version. You can read it and know what it does, you don't have to parse a few dozen version conditionals, runtime conditionals and random crap code that doesn't do anything in some gcc versions. In fact, I think I removed most of the no-op code. And now you can actually change something in the ebuild without caring for gcc3.4, or without breaking stuff for stable ebuilds. 2. USE flags are supposed to work. I've replaced the cases when they were silently ignored with REQUIRED_USE. I've also removed the silent removals when they didn't work -- so if your current toolchain is broken, things may actually fail instead of giving your different gcc than you wanted. Probably deserves explanatory pkg_pretend() at some point, with messages like 'disable USE=-foo because your toolchain is broken'. 3. Things simplified where they could have been simplified. For example, I removed the big gcc executable moving function and replaced it with --enable-version-specific-runtime-libs. It was enabled in toolchain.eclass with a comment 'If we enable it on non-Darwin we screw up the behaviour this eclass relies on.' So yep, precious cargo cult -- why enable something that would require you to remove your useless complex function?! 4. Added gx86-multilib love. Now you have abi_* flags to control the compiler runtime. Of course, since gcc is a pile of random modules not fit for one another it has different code for different targets. In particular, on mips you can't do two ABIs -- either single one (non-multilib) or all three of them (--enable-multilib). 5. Added multilib gcc wrappers. Long story short, multilib gcc now shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it doesn't screw up your system! Of course, the final implementation may differ since it's an early idea but it works. Now distcc happily builds stuff for your x86 clients. 6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen rather than silently skipping doc build when it's not installed... 7. Disabled bootstrap by default (and in fact completely for now). It is not *that* useful, and means time savings (and distcc support): Thu Nov 6 20:39:31 2014 sys-devel/gcc-4.9.2 merge time: 1 hour, 56 minutes and 43 seconds. Sun Dec 7 10:46:08 2014 sys-devel/gcc-4.9.2-r100 merge time: 34 minutes and 55 seconds. 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. If there is a real interest in my fork, I will probably move it to gx86 as sys-devel/gcc-mgorny. 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. Thanks, I've tried this on ~amd64. It builds in 10 minutes (wow!), tested to build some core stuff with it: kernel 3.17, glibc, coreutils, openssl, ssh... All seems to work fine. I'll try to recompile the whole machine with it. After emerge, there are these notices: * QA Notice: command not found: * * /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 3110: pax-mark: command not found *
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
Dnia 2014-12-08, o godz. 09:56:11 Alexis Ballier aball...@gentoo.org napisał(a): On Sun, 7 Dec 2014 11:37:57 +0100 Michał Górny mgo...@gentoo.org wrote: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. Could you please elaborate on this ? How and why this broke, what is wrong in glibc, what would be a sane crossdev alternative and how crossdev is not. 1. eblits are broken in glibc. Another case of incorrect interpretation of code sharing with love for breaking stable ebuilds. Plus I'd love to add multilib flags to it but we'll likely doing that to main glibc as well soon, if eblits don't get into our way. 2. crossdev is broken because it creates semi-random, unmaintained ebuilds in randomly chosen overlay, those ebuilds relying on toolchain.eclass behavior. 3. I don't have any real alternative design yet. However, one of the first ideas of changing crossdev is to replace copying ebuilds with symlinking gcc ebuild directory. This will at least ensure proper sync between real ebuilds and cross-ebuilds. -- Best regards, Michał Górny pgpxIrlqF6nnb.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
Dnia 2014-12-08, o godz. 07:27:51 Anthony G. Basile bluen...@gentoo.org napisał(a): On 12/07/14 08:18, Michał Górny wrote: 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. Hey! why don't I join QA so I can also fix eclasses that I find intrusive. Let's not make QA the final refuge of those who want to push through their preferences. Yes, that's exactly what occurred to me! Then I joined QA. But seriously saying, I didn't mean forcing anything on anyone myself. I meant starting proper QA process which could eventually hopefully result in QA prohibiting the use of current eclass in future ebuilds, and or referring to the Council about switching the default gcc provider. Of course, that's only the worst scenario. To proceed forward, you have bugs open against toolchain.eclass. The practice is to submit the patches to this list for review. If after awards you have community support, commit despite the maintainer's objections. Having obtained community support, you will have much more legitimacy against reverts. I can't speak for the whole council, but I would support you under such circumstances. I cannot support a position where QA simply asserts itself. When/if an appeal percolates up to the council, I will side with the maintainer under the argument that the commit to the eclass was not sufficiently reviewed. As I already said, the main issue simply can't be fixed this way. It's not that much *bugs in code in toolchain.eclass* but *what's in toolchain.eclass*. If we think of eclasses as libraries, then your library provides main() function. With conditionals for 14 consecutive releases of your program. And you already told people to link random stuff to it, and rely on every internal API detail. -- Best regards, Michał Górny pgpCY7C6hAMlb.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
В Tue, 9 Dec 2014 17:21:22 +0100 Michał Górny mgo...@gentoo.org пишет: Dnia 2014-12-08, o godz. 09:56:11 Alexis Ballier aball...@gentoo.org napisał(a): On Sun, 7 Dec 2014 11:37:57 +0100 Michał Górny mgo...@gentoo.org wrote: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. Could you please elaborate on this ? How and why this broke, what is wrong in glibc, what would be a sane crossdev alternative and how crossdev is not. 1. eblits are broken in glibc. Another case of incorrect interpretation of code sharing with love for breaking stable ebuilds. Plus I'd love to add multilib flags to it but we'll likely doing that to main glibc as well soon, if eblits don't get into our way. Yeah. Stable glibc ebuild gets broken from time to time after changes in eblits. 2. crossdev is broken because it creates semi-random, unmaintained ebuilds in randomly chosen overlay, those ebuilds relying on toolchain.eclass behavior. 3. I don't have any real alternative design yet. However, one of the first ideas of changing crossdev is to replace copying ebuilds with symlinking gcc ebuild directory. This will at least ensure proper sync between real ebuilds and cross-ebuilds. crossdev already works that way for a long time (see -oO option in help): $ ls -l /var/cache/portage/repos/crossdev/cross-armv6j-hardfloat-linux-gnueabi/ total 0 lrwxrwxrwx 1 portage portage 42 Oct 23 22:24 binutils - /var/cache/portage/tree/sys-devel/binutils lrwxrwxrwx 1 portage portage 37 Oct 23 22:24 gcc - /var/cache/portage/tree/sys-devel/gcc lrwxrwxrwx 1 portage portage 37 Oct 23 22:24 gdb - /var/cache/portage/tree/sys-devel/gdb lrwxrwxrwx 1 portage portage 38 Oct 23 22:24 glibc - /var/cache/portage/tree/sys-libs/glibc lrwxrwxrwx 1 portage portage 48 Oct 23 22:24 linux-headers - /var/cache/portage/tree/sys-kernel/linux-headers -- Alexander Tsoy
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On Tue, 9 Dec 2014 17:21:22 +0100 Michał Górny mgo...@gentoo.org wrote: Dnia 2014-12-08, o godz. 09:56:11 Alexis Ballier aball...@gentoo.org napisał(a): On Sun, 7 Dec 2014 11:37:57 +0100 Michał Górny mgo...@gentoo.org wrote: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. Could you please elaborate on this ? How and why this broke, what is wrong in glibc, what would be a sane crossdev alternative and how crossdev is not. 1. eblits are broken in glibc. Another case of incorrect interpretation of code sharing with love for breaking stable ebuilds. its a local toolchain.eclass yes Plus I'd love to add multilib flags to it but we'll likely doing that to main glibc as well soon, if eblits don't get into our way. keep in mind that, thanks to implicit system deps, you'll have to use.force what your toolchain is supposed to be able to produce. also, you'll probably face much more problems with bootstrapping than the cosmetics of eblits: get a gcc that can compile .o for your abi is easy, but you do not have the libc yet so can't link anything unless you use nodefaultlibs alike switches 2. crossdev is broken because it creates semi-random, unmaintained ebuilds in randomly chosen overlay, those ebuilds relying on toolchain.eclass behavior. it symlinks the dirs these days, so its not unmaintained toolchain.eclass behavior you're referring to is probably the category parsing to get CTARGET; this is very likely used in all other libc ebuilds so you'll have to fix them too; not mentioning the ability to update your cross toolchains with 'emerge world' that you cant do if you dont feed CTARGET in some way. 3. I don't have any real alternative design yet. However, one of the first ideas of changing crossdev is to replace copying ebuilds with symlinking gcc ebuild directory. This will at least ensure proper sync between real ebuilds and cross-ebuilds. as said above, this is the case here Alexis.
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On Sun, 7 Dec 2014 11:37:57 +0100 Michał Górny mgo...@gentoo.org wrote: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. Could you please elaborate on this ? How and why this broke, what is wrong in glibc, what would be a sane crossdev alternative and how crossdev is not. Alexis.
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On 12/07/14 08:18, Michał Górny wrote: 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. Hey! why don't I join QA so I can also fix eclasses that I find intrusive. Let's not make QA the final refuge of those who want to push through their preferences. To proceed forward, you have bugs open against toolchain.eclass. The practice is to submit the patches to this list for review. If after awards you have community support, commit despite the maintainer's objections. Having obtained community support, you will have much more legitimacy against reverts. I can't speak for the whole council, but I would support you under such circumstances. I cannot support a position where QA simply asserts itself. When/if an appeal percolates up to the council, I will side with the maintainer under the argument that the commit to the eclass was not sufficiently reviewed. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On Mon, Dec 8, 2014 at 7:27 AM, Anthony G. Basile bluen...@gentoo.org wrote: On 12/07/14 08:18, Michał Górny wrote: 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. Hey! why don't I join QA so I can also fix eclasses that I find intrusive. Let's not make QA the final refuge of those who want to push through their preferences. To proceed forward, you have bugs open against toolchain.eclass. The practice is to submit the patches to this list for review. If after awards you have community support, commit despite the maintainer's objections. Having obtained community support, you will have much more legitimacy against reverts. I can't speak for the whole council, but I would support you under such circumstances. I cannot support a position where QA simply asserts itself. When/if an appeal percolates up to the council, I will side with the maintainer under the argument that the commit to the eclass was not sufficiently reviewed. ++ regarding how QA should operate. I have no issues with him forking the ebuild and doing things his own way though. -- Rich
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On 12/07/14 17:41, William Hubbs wrote: 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 bas...@opensource.dyc.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. Hardened has used the eclass in its overlay and continues to use it. We do not wish to get rid of it. @hardened, we should discuss this at our next meeting. 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. I'm not sure what you mean by old code which is no longer really supported upstream. gcc is built using gcc. We should have a window on gcc versions which goes backwards and forwards a couple of versions, so I can build 4.8 with 4.7 or 4.6 and vice versa. And build 4.6 with 4.5 or 4.4, etc. There is an entire chain there. Keeping the detailed decisions in an eclass of what features were on/off for each version makes sense so we can conveniently track that chain. When I say I want to keep history, that's what I'm talking about. In hardened we went through a pains taking process of making sure the first hardened gcc-4 versions (4.4 I believe) was buildable by the previous one, and that it could build itself and could rebuild itself both adding and remove hardening etc. (BTW by we I mean Magnus who deserves all the kudos. I just helped with testing and told him what broke.) If you want to simplify code, then let's bump all the gcc ebuilds to EAPI 4 or above and refactor the phase functions and remove all the EAPI checks. But removing all instances of tc_version_is_* is not a good idea. 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. But not certain embedded systems or other scenarios. gcc-3 for instance did hardening differently than 4. While I'm not as interested in gcc-2, I don't want to see gcc-3 dumped. Even minor leaps like 4.7 to 4.8 introduced deep changes like requiring c++. Its easy to say, why do we need this? when one forgets that evolution, or was never familiar with it. This
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On 12/08/14 07:32, Rich Freeman wrote: On Mon, Dec 8, 2014 at 7:27 AM, Anthony G. Basile bluen...@gentoo.org wrote: On 12/07/14 08:18, Michał Górny wrote: 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. Hey! why don't I join QA so I can also fix eclasses that I find intrusive. Let's not make QA the final refuge of those who want to push through their preferences. To proceed forward, you have bugs open against toolchain.eclass. The practice is to submit the patches to this list for review. If after awards you have community support, commit despite the maintainer's objections. Having obtained community support, you will have much more legitimacy against reverts. I can't speak for the whole council, but I would support you under such circumstances. I cannot support a position where QA simply asserts itself. When/if an appeal percolates up to the council, I will side with the maintainer under the argument that the commit to the eclass was not sufficiently reviewed. ++ regarding how QA should operate. I have no issues with him forking the ebuild and doing things his own way though. -- Rich Forking code does not address the QA issues currently against toolchain.eclass. The two issues are orthogonal and I don't think I connected them in my emails. I disagree with forking but have no right to obstruct it and would not. In that respect, I'm simply voicing my opinion as a dev. However regarding how QA should operate, I am operating with the guidelines of gentoo self-governance. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On Mon, Dec 8, 2014 at 9:00 AM, Anthony G. Basile bluen...@gentoo.org wrote: Forking code does not address the QA issues currently against toolchain.eclass. The two issues are orthogonal and I don't think I connected them in my emails. I disagree with forking but have no right to obstruct it and would not. In that respect, I'm simply voicing my opinion as a dev. However regarding how QA should operate, I am operating with the guidelines of gentoo self-governance. ++ Honestly, I don't think internal forks are terribly helpful either in the long run. Sometimes they seem to be needed at some point to at least push things along, but obviously it would be better to focus on one package. I just don't want to be critical of those who want to fork things, as they usually have very legitimate concerns and at least by forking they're producing something new that people can play with and test, which can help us cross the gap from where we are to where we want to be. A big reason there are forks is that sometimes people just get fed up with trying to work with people and would prefer to go do something even if it basically means re-inventing the wheel. I was thinking about this earlier today after being somewhat frustrated with a completely different FOSS issue. The nature of Gentoo tends to draw a lot of people who want to achieve their vision of technical perfection. This makes it really hard for all of us to work together. I'll admit that there are times I get sick of some of the debates on the lists/etc, and I'm sure everybody on all sides of every issue tends to feel the same way. We keep coming back because we think there is something here worth fighting for, and sometimes even worth compromising for. Forks can be a way to try out new things, and turning theoretical arguments into practical comparisons. Sure, they can also be incredible wastes of time, but so is just about anything that any of us do for fun. I think that creating something new is far more productive than arguing on lists, even if in the end the work gets abandoned (though this is rarely the case - usually something gets re-appropriated which is the whole point of FOSS). Forks are also a great way to get new blood into an arcane subject - making incremental changes on a mature codebase is often a lot harder than making incremental changes on a new codebase that likely leaves out 50% of the corner cases. If we don't have friendly internal competition, it will just make it that much harder to stay relevant. Let's just try to keep it friendly. :) -- Rich
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On Sun, Dec 7, 2014 at 5:05 AM, Anthony G. Basile bas...@opensource.dyc.edu wrote: 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. Yes, but while your claim that it reduces reusability is true, I think that's potentially a good thing. With all of the logic encoded in that huge eclass, any modifications to it change the code any version of the gcc ebuild executes, including stable versions that you're not thinking about at the time. eclasses are pretty great for sharing code akin to a library, but when *all* of your ebuild's logic is in the eclass, well, that's not really the intended use case as far as I can tell. glibc does the same thing with eblits. I think I remember Ciaran making the same argument in the past, but much better said than mine.
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On Mon, Dec 8, 2014 at 12:08 PM, Matt Turner matts...@gentoo.org wrote: eclasses are pretty great for sharing code akin to a library, but when *all* of your ebuild's logic is in the eclass, well, that's not really the intended use case as far as I can tell. It works well in cases like KDE where you have 300 ebuilds that all just set a few environment variables and then genuinely share common code for everything else. Also, major updates only come once every few years, which helps keep the eclass from becoming a rat's nest. I think it is better to just version an eclass instead of having a mess of conditionals based on version, but then we'd have 300 revisions of toolchain.eclass (which is probably a good hint that we're doing it wrong). A library is a good analogy of how to avoid all of this. Each function does one thing well, and you call them as you need them, and you don't tweak their APIs 10 times per year. And if you find you're never using a function more than once after doing this, then you don't need a library in the first place. -- Rich
[gentoo-dev] sys-devel/gcc::mgorny up for testing
Hello, developers and users. As some of you know, the toolchain packages in Gentoo suffer from lack-of-sanity issues and their maintainers are completely unwilling to improve things. I have finally decided to start working on a fork of the sys-devel/gcc ebuilds, and I have some bits ready for initial testing in 'mgorny' repo, so I would like to know your opinion. Before you start, the shortcomings are: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. 2. No gcj support. Since the ebuild has been forked out of toolchain.eclass, and the gcj support suffers a lot of issues there, I decided there's no point in copying the code. Not sure if anybody actually uses it, and if it is actually useful for anything but will probably get reintroduced one day [above 'if' applies too]. 3. No bootstrapping, fallbacks and possible some other random feature support. The goal was pretty much to get gcc compiling first, and avoid awful lot of effort if things prove to have no future. 4. Hardened is not tested. I think I have copied all the needed code and fixed some stuff but I have no clue if it still works ;). Now, the major changes are: 1. Most of the insanity removed. No more toolchain.eclass. The ebuild has just the code for the current gcc version. You can read it and know what it does, you don't have to parse a few dozen version conditionals, runtime conditionals and random crap code that doesn't do anything in some gcc versions. In fact, I think I removed most of the no-op code. And now you can actually change something in the ebuild without caring for gcc3.4, or without breaking stuff for stable ebuilds. 2. USE flags are supposed to work. I've replaced the cases when they were silently ignored with REQUIRED_USE. I've also removed the silent removals when they didn't work -- so if your current toolchain is broken, things may actually fail instead of giving your different gcc than you wanted. Probably deserves explanatory pkg_pretend() at some point, with messages like 'disable USE=-foo because your toolchain is broken'. 3. Things simplified where they could have been simplified. For example, I removed the big gcc executable moving function and replaced it with --enable-version-specific-runtime-libs. It was enabled in toolchain.eclass with a comment 'If we enable it on non-Darwin we screw up the behaviour this eclass relies on.' So yep, precious cargo cult -- why enable something that would require you to remove your useless complex function?! 4. Added gx86-multilib love. Now you have abi_* flags to control the compiler runtime. Of course, since gcc is a pile of random modules not fit for one another it has different code for different targets. In particular, on mips you can't do two ABIs -- either single one (non-multilib) or all three of them (--enable-multilib). 5. Added multilib gcc wrappers. Long story short, multilib gcc now shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it doesn't screw up your system! Of course, the final implementation may differ since it's an early idea but it works. Now distcc happily builds stuff for your x86 clients. 6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen rather than silently skipping doc build when it's not installed... 7. Disabled bootstrap by default (and in fact completely for now). It is not *that* useful, and means time savings (and distcc support): Thu Nov 6 20:39:31 2014 sys-devel/gcc-4.9.2 merge time: 1 hour, 56 minutes and 43 seconds. Sun Dec 7 10:46:08 2014 sys-devel/gcc-4.9.2-r100 merge time: 34 minutes and 55 seconds. 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. If there is a real interest in my fork, I will probably move it to gx86 as sys-devel/gcc-mgorny. 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. -- Best regards, Michał Górny pgpmJHeoXvp15.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/2014 04:37 AM, Michał Górny wrote: Hello, developers and users. As some of you know, the toolchain packages in Gentoo suffer from lack-of-sanity issues and their maintainers are completely unwilling to improve things. I have finally decided to start working on a fork of the sys-devel/gcc ebuilds, and I have some bits ready for initial testing in 'mgorny' repo, so I would like to know your opinion. Before you start, the shortcomings are: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. 2. No gcj support. Since the ebuild has been forked out of toolchain.eclass, and the gcj support suffers a lot of issues there, I decided there's no point in copying the code. Not sure if anybody actually uses it, and if it is actually useful for anything but will probably get reintroduced one day [above 'if' applies too]. 3. No bootstrapping, fallbacks and possible some other random feature support. The goal was pretty much to get gcc compiling first, and avoid awful lot of effort if things prove to have no future. 4. Hardened is not tested. I think I have copied all the needed code and fixed some stuff but I have no clue if it still works ;). Now, the major changes are: 1. Most of the insanity removed. No more toolchain.eclass. The ebuild has just the code for the current gcc version. You can read it and know what it does, you don't have to parse a few dozen version conditionals, runtime conditionals and random crap code that doesn't do anything in some gcc versions. In fact, I think I removed most of the no-op code. And now you can actually change something in the ebuild without caring for gcc3.4, or without breaking stuff for stable ebuilds. 2. USE flags are supposed to work. I've replaced the cases when they were silently ignored with REQUIRED_USE. I've also removed the silent removals when they didn't work -- so if your current toolchain is broken, things may actually fail instead of giving your different gcc than you wanted. Probably deserves explanatory pkg_pretend() at some point, with messages like 'disable USE=-foo because your toolchain is broken'. 3. Things simplified where they could have been simplified. For example, I removed the big gcc executable moving function and replaced it with --enable-version-specific-runtime-libs. It was enabled in toolchain.eclass with a comment 'If we enable it on non-Darwin we screw up the behaviour this eclass relies on.' So yep, precious cargo cult -- why enable something that would require you to remove your useless complex function?! 4. Added gx86-multilib love. Now you have abi_* flags to control the compiler runtime. Of course, since gcc is a pile of random modules not fit for one another it has different code for different targets. In particular, on mips you can't do two ABIs -- either single one (non-multilib) or all three of them (--enable-multilib). 5. Added multilib gcc wrappers. Long story short, multilib gcc now shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it doesn't screw up your system! Of course, the final implementation may differ since it's an early idea but it works. Now distcc happily builds stuff for your x86 clients. 6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen rather than silently skipping doc build when it's not installed... 7. Disabled bootstrap by default (and in fact completely for now). It is not *that* useful, and means time savings (and distcc support): Thu Nov 6 20:39:31 2014 sys-devel/gcc-4.9.2 merge time: 1 hour, 56 minutes and 43 seconds. Sun Dec 7 10:46:08 2014 sys-devel/gcc-4.9.2-r100 merge time: 34 minutes and 55 seconds. 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. If there is a real interest in my fork, I will probably move it to gx86 as sys-devel/gcc-mgorny. 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. As a user, what would adopting this do? For instance I run ~amd64 multilib and have had quite a time dealing with the recent multilib changes (specifically with Humble Bundle games). Would you recommend helping you test this simplified and/or cleaned up toolchain on one's primary system, or is it better off for more specific systems that don't need to be as versatile as a multi-purpose desktop machine? Regardless, it seems really ambitious and I hope positive change comes about for the toolchain. -BEGIN PGP SIGNATURE- Version:
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
Dnia 2014-12-07, o godz. 04:43:05 Daniel Campbell cont...@sporkbox.us napisał(a): 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. If there is a real interest in my fork, I will probably move it to gx86 as sys-devel/gcc-mgorny. 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. As a user, what would adopting this do? For instance I run ~amd64 multilib and have had quite a time dealing with the recent multilib changes (specifically with Humble Bundle games). Would you recommend helping you test this simplified and/or cleaned up toolchain on one's primary system, or is it better off for more specific systems that don't need to be as versatile as a multi-purpose desktop machine? I wouldn't run it on production system, or when you need crossdev with 4.9.2. If you're on Hardened or some less common system, I wouldn't try it as the primary compiler. Also, best if you have a backup gcc or binary package you can downgrade to (quickpkg --include-configs=y gcc). That said, I'm running it on all my ~amd64 and ~x86 systems and it works. I've rebuilt all packages on my devbox using it and nothing (new) failed. However, I didn't try building it using gcc-4.8. -- Best regards, Michał Górny pgpweEuQ2mrd0.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
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
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
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
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On Sun, Dec 7, 2014 at 8:05 AM, Anthony G. Basile bas...@opensource.dyc.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. 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? 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? 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 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. Agree somewhat. Forking is perfectly fine - a complete non-issue. Trying to exclude the other branch in the name of QA is something we need to be careful about and consider on the merits. If somebody wants to add yet another gcc implementation to the tree and it is really lousy, I don't really have a problem with it if it builds and doesn't contain security issues, etc. I think people sometimes try to make QA into something that it isn't. In the same way there is nothing wrong with the existing gcc implementation being completely unmaintainable and obsolete as long as it builds and doesn't contain security issues. I think the real issue we run into in these kinds of cases is namespace. If I want to add my own competing ebuild for chromium I can't call it chromium. -- Rich
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
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 bas...@opensource.dyc.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 signature.asc Description: Digital signature
