does cmake really need to blacklist macports-clang >= 3.8?
René J.V. Bertin
rjvbertin at gmail.com
Sat Dec 9 21:16:06 UTC 2017
On Saturday December 09 2017 11:36:14 Ryan Schmidt wrote:
>It should be used as a developer debugging tool. It should never be required for end users to install a port. If it is, it is a bug in the port's or its dependencies' compiler selection / blacklisting.
One thing that straightforward compiler selection/blacklisting doesn't do is pick the most capable (= most recent) of the available valid options. It's possible to write the blacklisting instructions in such a way that a build will automatically use the latest compiler but the standard approach typically has the opposite effect.
Earlier today I ran into a situation where I needed to use a non-default (and more recent) compiler for a reason I cannot blame the port for: building a library for optimal performance (including the options -march=native and -flto). I think that's a valid and justifiable use-case for using configure.optflags, and in this case it caused a linker failure because the system compiler (clang 600.x) apparently generates SSE intrinsics that the linker (from port:ld64) no longer recognises.
Before I upgraded to OS X 10.9 I often had to resort to using GCC >= 4.8 in order to build code written in too modern C++ dialects and I guess this is still an option for users of pre-10.9 systems who chose not to do the libc++ conversion.
R.
More information about the macports-dev
mailing list