likewise, if I look at the compilers PG
https://github.com/macports/macports-ports/blob/master/_resources/
port1.0/group/compilers-1.0.tcl
the list there is also already restricted to
lappend gcc_versions 5 6 7 8 9
if I am parsing things correctly.
So, where exactly are the gcc compilers 10 to 14 entering the game
currently for builds on <10.6 ?
I guess we are back to the point about the issue being not really with
the gcc-N ports, but the libgcc-N ports as it is there where the
dependency tree currently lives.
So taking gcc10 as an example, to install this from scratch you need
gcc10
libgcc10
libgcc11
libgcc12
libgcc13
libgcc14
and removing those ports that are just stub ports so building takes no time
gcc10
libgcc10
libgcc11
libgcc14
so compared to the minimum, which would be 2 builds (one gccN and one
libgccM build) we are taking 4 builds instead of 2.
So yes, its twice the builds you in theory would need in the best case
scenario. Whilst not ideal, this is (for me) hardly the nightmare
scenario people seem to be making it out to be.
( Also note, I suspect a number of those builds *could* be made stub
ports, but currently they are not, either because the port is badly
written or by giving up on some optional functionalities, like sanitizer
libs)
My problem with what you are proposing is changing how the dependencies
between the various libgccN ports is currently configured, to be
different on <10.6 to the newer OSes, is likely going to be waay more
messy than I think you are currently anticipating. To my eye, trying to
reduce as many libgccN ports down to basic stub ports that become
trivial to install is the better way forward).
Chris
