Sent: Friday, November 12, 2021 at 8:08 PM From: "Eric Borisch"
> Just looking for anyone interested to provide feedback on this: > https://github.com/macports/macports-ports/pull/12933 > It uses '-Xpreprocessor -fopenmp' to get Apple's clang to compile OpenMP > code; it still relies on libomp for omp.h / -lomp, but doesn't require > clang-x.x to compile. > Not an official route, but it works; thanks to M.P. for the tip. More general comments about this approach: This seems to resemble -Xclang -fopenmp suggested in https://lists.macports.org/pipermail/macports-dev/2020-October/042519.html and https://mac.r-project.org/openmp/ (although I do not know why different libomp binaries are required for different Xcode versions; I’m not aware of MacPorts’ libomp being similarly limited to use with a specific LLVM version). I’m unaware what the difference is with the -Xpreprocessor -fopenmp approach. I think it would be preferable to have compiler.openmp_version allow using Xcode clang (if compatible) to reduce port-specific tricks. > Certainly this "trick" could stop working with any new XCode release. I feel this is unlikely given upstream Clang support, even though Apple will likely never officially support OpenMP (especially given their own alternatives for parallelism; the most portable supported approach is probably POSIX threads). Is compatibility with OpenMP (or later versions of it) only present in later Xcode clang versions? If so, can this be inferred from the corresponding upstream LLVM version? Is it okay if the extra flags needed for Xcode clang are passed to MacPorts’ LLVM clang instead, in case ports request a newer compiler? Also, I had previously been discouraged from enabling in OpenMP in ports due to pkgconfig-related issues, so I’ve only considered enabling it in ports for command line utilities rather than libraries (I don’t know if that included GraphicsMagick).
