py-numpy: Compiler clang37 not available for Darwin20 arm

[ryandesign (Ryan Carsten Schmidt)]

​https://build.macports.org/builders/ports-11_arm64-builder/builds/13531/steps/install-dependencies/logs/stdio

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
Compiler clang37 not available for Darwin20 arm
    while executing
"compilers.setup         -clang -gcc44 -gcc45  -gcc46 -gcc47 -gcc48 -g95 clang37"
    invoked from within
"if {${name} ne ${subport}} {
    set PATCH_PY_EXT ""
    if {${python.version} == 27} {
        github.setup        numpy numpy 1.16.6 v
        check..."
    (file "Portfile" line 50)
    invoked from within
"source Portfile"
    invoked from within
"$workername eval {source Portfile}"
    (procedure "mportopen" line 50)
    invoked from within
"mportopen $dep_portinfo(porturl) $dep_options $variations"
    (procedure "mportdepends" line 126)
    invoked from within
"mportdepends $mport "activate""
    invoked from within
"if {[mportdepends $mport "activate"] != 0} {
    ui_error "mportdepends $portname activate failed."
    exit 1
}"

[Schamschula (Marius Schamschula)]

There is nothing in py-tifffile that asks for a specific compiler.

However, I get the same error when trying to do port info py39-numpy.

[ryandesign (Ryan Carsten Schmidt)]

Right, sorry.

[jmroot (Joshua Root)]

It seems really inconvenient that each port needs to check which platform it's on and only ask for compilers that are supported on that platform. Couldn't that be handled by the portgroup?

[cjones051073 (Chris Jones)]

The port group now issues a warning if a port asks to remove an already not available compiler, but still considers a port asking for one a hard error

​https://github.com/macports/macports-ports/blob/f9f395ba65eb4a15eb41dcbaf4a91b74ef8559be/_resources/port1.0/group/compilers-1.0.tcl#L644

Sure, this could be changed, but what should the PG do ? In this case the port is only asking for one, rather old, compiler, so I dont really see what can be done. I think in this case the port also needs to be updated a bit.

[cjones051073 (Chris Jones)]

Thinking about it, the only way I see to do this is to remove from ports like this the explicit requesting of a compiler variant, and instead only list those they don't want. Then the PG can figure out for itself what the remaining set of compilers are for a given platform.

[jmroot (Joshua Root)]

Now py27-scipy is failing in a really strange and problematic way: ​https://build.macports.org/builders/ports-11_arm64-watcher/builds/3877/steps/subports/logs/stdio

It doesn't fail to mportopen, but then a variable that should always be set, isn't.

[cjones051073 (Chris Jones)]

Its probably this

Warning: port "py27-scipy" failed to open: Compiler clang37 not available for Darwin20 arm

The port also explicitly adds the clang37 compiler to the list, so I guess it needs removing there as well.

[cjones051073 (Chris Jones)]

[aa17fa185fc80e0d06ba01b941e35de2a141b01c/macports-ports]

[jmroot (Joshua Root)]

Removing clang37 is all very well, but it's still a real problem that this code can break a port that badly.

[cjones051073 (Chris Jones)]

I would argue all the change has done is expose an issue that was already there, namely declaring variants for compilers which could never have worked on a number of platforms. This issue isn’t jsut for arm, its also there for intel, just that we haven’t yet cleaned up the list there.

As i said, we could decide to make requesting to add a compiler variant a warning and not a hard error as it still is. That would be trivial to do, I am just not sure its the right thing to do.