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 <chrischa...@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
