On 21/11/2024 3:34 pm, Chris Jones via macports-dev wrote:
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).
So, I just took a look at what is actually installed by the binary
tarballs for OSX10.6 (the oldest I can check via
https://packages.macports.org/) got gcc versions 7 through to 13
Of these the only versions that install any dylibs (and thus are not in
practise just stub ports) are
libgcc7
libgcc9
thats it !
of the others, I think these are currently not correctly configured as
stub ports and thus build is actually run, but in the end nothing is
done with it
libgcc8
libgcc10
libgcc11
these are already properly configured as stub ports
libgcc12
libgcc13
So the very first thing that someone should do is fix these three ports
libgcc8
libgcc10
libgcc11
to avoid running the build needlessly.
Once done, the number of (real) builds you will actually need with the
current dep tree will be much much reduced.
Chris
p.s. Obviously I have the caveat I do not know what happens on <10.6
machines. Someone with access to these should run
> port contents libgccN
for each of them and report what is actually there· If all you see is
something like
pcmf ~/Downloads/gcc > tar -jxvf libgcc8-8.5.0_1.darwin_10.x86_64.tbz2
./
./+COMMENT
./+CONTENTS
./+DESC
./+PORTFILE
./+STATE
./opt/
./opt/local/
./opt/local/share/
./opt/local/share/doc/
./opt/local/share/doc/libgcc8/
./opt/local/share/doc/libgcc8/README
then the port is just a stub port and the build should be disabled to
avoid needlessly running it.
Chris
