This commit deduplicates the copy-pasted gcc mess in
pkgs/top-level/all-packages.txt, replacing it with a single
expression that branches based on the chosen version.
This refactoring has exposed several bizzare behaviors in our
historical gcc expressions. These are almost certainly a result of
people reaching back and making a change only to the version they
care about, and neglecting adjacent versions. These oddities went
un-noticed because in copy-paste-duplicated form it is nearly
impossible to notice what has happened.
When refactored into branch-on-version form, the irregularities jump
out at you:
1. The ISL version we are using jumps *backward* from 0.14 on gcc48
to 0.11 on gcc49, then forward again at gcc6. If gcc49 cannot
use isl 0.14 why is gcc48 able to? I doubt this is right, but if
it is there should be an explanatory comment, and I found none.
2. gcc6 bumps to isl 0.17 only if compiling for RedoxOS. This
probably means that gcc6 is able to use isl 0.17 everywhere. If
not, there should have been a comment explaining why RedoxOS is
special here.
3. gcc49 on Darwin uses gccStdenv because "build fails on Darwin
with clang"; surely if that is the case then that is true for
gcc48 as well, no?
4. gcc49 overrides cloog to v0.18.0, but gcc48 doesn't. Again, very
weird, probably somebody meant to override gcc 4.9 *and all older
versions*, not just that one particular version.
5. when cross-compiling, gcc6,7,8 override stdenv to gcc7Stdenv
because "gcc 10 is too strict to cross compile gcc <= 8" yet this
override was not applied to any other versions of gcc which are
"<= 8". It's also odd that gcc7Stdenv is used rather than
gcc8Stdenv.
The best part about switch-on-version form is that oversights like
the above *make the code more verbose* so they stand out. Fixing
these likely-bugs will make the code simpler and shorter. In
copy-paste-duplicated style the opposite is true: you get shorter
code by *forgetting* to apply changes to all the versions that need
the change! That's a very perverse incentive.
This PR does not attempt to change or fix any of these behaviors. I
have confirmed that it does not affect eval (same drv-hash) for all
gcc versions on both x86_64-linux and x86_64-darwin.
