[MacPorts] #61327: py-rpy2 build fails with clang: error: unsupported option '-fopenmp'

[Ken Cunningham]

We’d need:

1. the ability to install and keep a toolchain on the buildbot in some fashion

I’m very in favour of this, if possible, but I can see that it is not trivial to implement — I think all the OS versions < about 10.12 should use clang-9.0 to build everything, and save us all a lot of trouble making ancient clangs work with current software (or vice versa, I guess).

2. an “openmp” PortGroup that all ports that want openmp could subscribe to, that forces an openmp setup that works for various systems.

Not overly hard, I think.

BTW I’m all in favour, should this be agreeable to all, as you have seen from the several tickets I opened aboutit. 

I tried to encourage openmp support a couple of years ago, and ran into pushback due to these unresolved issues.

Ken





> On Oct 15, 2020, at 8:57 PM, Christopher Chavez <chrischavez at gmx.us> wrote:
> 
>> Comment (by kencu):
> 
>> …Ryan has made it clear he does not want every build to be forced to a
>> macports clang compiler as that causes the drives on the buildbots to die
>> prematurely due to all the installing and uninstalling of macports-
>> clang-9.0 (or whichever is the head of the line at that time).
> 
> Is this really something with no chance of being addressed, and which port maintainers and users will have to live with? Is it undesirable to swap-in another MacPorts prefix with e.g. clang 9.0 permanently installed? Or, rather than writing extracted ports to disk to install them, is it possible on macOS/would it not be undesirable to mount a prebuilt port's compressed archive and then overlay/union it at the prefix?
> 
>> And this is indeed how we came to disable openmp in virtually all builds,
>> until Apple clangs supported openmp (which we all thought might happen
>> before now, but has not happened).
> 
> My impression is that this will never happen. It seems Apple would rather you use whatever other choices for parallelism on their platform, such as Grand Central Dispatch and Metal Compute, which they have more influence/control over, which are usable from Swift, and can take advantage of SIMD on newer CPUs/GPGPUs. POSIX threads might be one of the only cross-platform options natively supported.
> 
>> I would suggest we go back to disabling openmp for 99.99% of cases, unless
>> people can sort this out for a specific lonely build, in a specific case,
>> that can affect no other software.
> 
> Pardon my naïvety on this whole subject, but I think it really would be nice if MacPorts could offer the more performant choice without requiring users to opt-in to variants (if they know what those are) or build locally. OpenMP seems like a good way to support the increasing number of CPU cores in systems without relying on non-backward-compatible SIMD CPU instructions (unless those are what the SIMD support in recent OpenMP versions tries to use). I think leaf ports such as for command-line utilities would be a good place to start enabling OpenMP.
> 
> Christopher A. Chavez