> 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
