Ports fail to parse after changes to gcc_compilers.tcl

[ryandesign (Ryan Carsten Schmidt)]

​https://build.macports.org/builders/ports-11_arm64-watcher/builds/3749/steps/checkout/logs/stdio

Failed to parse file python/py-pytorch/Portfile: no such mpi package: gcc44
Failed to parse file science/molden/Portfile: no such compiler: gcc10

[cjones051073 (Chris Jones)]

Yeah, not un expected. Ports that assume all compilers are available will need updating to reflect only a subset are available on arm.

[ryandesign (Ryan Carsten Schmidt)]

Why?

All molden is doing with gcc10 is specifying that it is not acceptable. Why should that cause it to fail to parse, even if gcc10 was not among the list of acceptable choices on arm to begin with?

[cjones051073 (Chris Jones)]

Sorry, I wasn't clear. I meant I wasn't surprised there would be a few problems.

I've been looking into it and it looks like its a flaw in the logic in the mpi and compilers portgroups. Both issue a hard error if a port turns off a compiler option that isn't available. I agree that in this case it shouldn't. I'll work on an update to do this.

[cjones051073 (Chris Jones)]

[5c7cf402b57be8cb4d14b78c4024b9a3375a27a9/macports-ports]

[ryandesign (Ryan Carsten Schmidt)]

Ok, but we still have a problem for ports that specify a compiler that won't work.

For example, py-numpy specifies clang37 which won't work on arm64. Fine. The port can't be installed and should emit an error when the user attempts to install it. But it is not fine that the port fails to work at all, even to the point that port info doesn't work:

% port info py39-numpy
Warning: Compiler gcc44 not available for Darwin20 arm
Warning: Compiler gcc45 not available for Darwin20 arm
Warning: Compiler gcc46 not available for Darwin20 arm
Warning: Compiler gcc47 not available for Darwin20 arm
Warning: Compiler gcc48 not available for Darwin20 arm
Error: Unable to open port: Compiler clang37 not available for Darwin20 arm

It's not fine that if I schedule a batch of port builds and one of them depends on py-numpy the entire batch fails to be scheduled:

​https://build.macports.org/builders/ports-11_arm64-watcher/builds/3825

Compiler clang37 not available for Darwin20 arm
    while executing
"compilers.setup         require_fortran -clang -gcc44 -gcc45 -gcc46 \
                        -gcc47 -gcc48 -g95 clang37"
    (file "Portfile" line 29)
    invoked from within
"source Portfile"
    invoked from within
"$workername eval {source Portfile}"
    (procedure "mportopen" line 50)
    invoked from within
"mportopen $portInfo(porturl) [list subport $portInfo(name)] $variantInfo"
    (procedure "infoForPort" line 26)
    invoked from within
"infoForPort $aPort $variantInfo"
    (procedure "check_licenses" line 43)
    invoked from within
"check_licenses $portinfo(name) [list]"
    ("while" body line 99)
    invoked from within
"while {[llength $todo] > 0} {
    set p [lindex $todo 0]
    set todo [lrange $todo 1 end]

    if {![info exists portdepinfo($p)]} {
        if {[cat..."
    (file "/opt/bblocal/var/buildworker/ports/build/mpbb/tools/sort-with-subports.tcl" line 213)
./mpbb/mpbb: error: None of the specified ports were found in the port index.
./mpbb/mpbb: error: `list-subports' failed to run successfully

[jmroot (Joshua Root)]

Replying to ryandesign:

For example, py-numpy specifies clang37 which won't work on arm64. Fine. The port can't be installed and should emit an error when the user attempts to install it.

It doesn't actually need clang37 in general, it asks the portgroup to add a clang37 variant. The only time an error should result is if the user tries to install with that variant. But it seems like simply not creating that variant on arm64 would be fine.

[jmroot (Joshua Root)]

Replying to ryandesign:

It's not fine that if I schedule a batch of port builds and one of them depends on py-numpy the entire batch fails to be scheduled:

That's a different bug. Should be fixed now.

[ryandesign (Ryan Carsten Schmidt)]

Oh great thank you!

[cjones051073 (Chris Jones)]

As I mention in #62480 ports explicitly requesting compiler variants is I think problematic as to do that the ports really need to know what they are requesting is available on any given platform. I think in general ports should only list the compilers they do not want variants for, and then allow the PG to merge that with its known list of compilers available for a given platform to create the set of compatible compiler variants.

[cjones051073 (Chris Jones)]

Also, just a side note when I update the compilers PG to remove the unavailable compilers for arm, I noted we are still incorrect for intel. see

​https://github.com/macports/macports-ports/blob/452b144f54b61204987cab59507455f0ff88d5ec/_resources/port1.0/group/compilers-1.0.tcl#L97

​https://github.com/macports/macports-ports/blob/452b144f54b61204987cab59507455f0ff88d5ec/_resources/port1.0/group/compilers-1.0.tcl#L139

both those lines assume the full list of gcc and clang compilers are OK for every OS, which is not the case. Many of the older compilers are not available on newer OS, so we also should sometime tweak the list for intel machines to reflect this.

[cjones051073 (Chris Jones)]

It seems the clang37 variant was only added to address

#58771

but the need for it has since been removed, so I think its no longer required and can be just removed.

[Chris Jones <jonesc@…>]

In d421dc8e88be348fd32468009f83d6cced95dab9/macports-ports (master):

py-numpy: remove no longer required clang37 variant
Closes: #62470