[gentoo-dev] sys-devel/gcc::mgorny up for testing

[Michał Górny]

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