Cotire 1.8.0 does not work with AppleClang 8.0.0

[macdew]

The new clang command line parameter added for Cotire 1.8.0: -fno-pch-timestamp is not supported on my version of AppleClang 8.0.0. I've guarded it with if (APPLE) as a workaround for now.

[ryandesign]

This prevents et (EternalTerminal) from being built on some macOS versions because et uses cotire.

The problem seems to be that when the compiler id matches "Clang" your condition for adding -fno-pch-timestamp is whether the clang version is >= 4.0.0:

https://github.com/sakra/cotire/blob/master/CMake/cotire.cmake#L1673-L1694

The problem is that you were probably thinking of the open-source clang version numbering scheme. On macOS, Xcode include's Apple's flavor of clang which has a completely different version numbering scheme. For example, Apple clang 8 was released inside Xcode 8 back in September 2016, 6 months before open source clang 4 was released in March 2017.

By default cmake classifies both open-source clang and Apple clang as the compiler id "Clang". If you set CMP0025=NEW then Apple clang will be identified as the compiler id "AppleClang" so that you can check it separately. MacPorts does set CMP0025=NEW, but since you're currently checking if the compiler id matches "Clang" that will match both "Clang" and "AppleClang".

As you can see, inferring compiler capabilities based on version number checks is error prone. If you can do it with cmake, it would be more reliable to do feature tests: actually invoke the compiler with your candidate flag, see if the compiler produces an error, and use that result to decide whether to use the flag in your build.