Improve detection of Clang and when to add compiler flags
advanced disk information utility
Brought to you by:
bll123
Menu
▾
▴
#17 Improve detection of Clang and when to add compiler flags
In di 5.0.3, CMakeLists.txt adds some flags when CMAKE_C_COMPILER_ID STREQUAL "Clang". Apple maintains a fork of Clang (distributed with Xcode and its command line tools) that is different enough to warrant being distinguished from the original llvm.org Clang. Therefore when CMP0025 is NEW, CMake identifies Apple Clang by the compiler ID AppleClang instead of Clang. Although the default of CMP0025 is currently OLD, that may change in a future CMake version. The MacPorts CMake build infrastructure sets CMP0025 to NEW. The MacPorts CMake build infrastructure is not currently being used for di because of the need to use di's wrapper Makefile. You mentioned that in di 5.0.4 the use of the wrapper Makefile will no longer be required. If at that time we switch to using the MacPorts CMake build infrastructure, the way that CMakeLists.txt currently identifies Clang will stop working when using Apple Clang and none of your Clang-specific flags will be set. The simple fix is to change STREQUAL to MATCHES however I recommend a different approach.
In that section of CMakeLists.txt, there are also two flags added conditionally. One flag is only added when APPLE. I presume this was meant to target Apple Clang, however it is not unreasonable to use the original llvm.org Clang on Apple systems, so this might add a flag that llvm.org Clang doesn't understand. Another flag is only added when CMAKE_CLANG_COMPILER_VERSION VERSION_GREATER_EQUAL "16.0.0". Apple Clang and llvm.org Clang have different version numbering schemes, as you can see on Wikipedia. The "LLVM" column shows the llvm.org version number while the "Clang version string" column shows the Apple version number. Therefore before you do any version number comparisons on the Clang version number you need to establish whether Apple Clang or llvm.org Clang is being used. But again I recommend a different approach.
Instead of trying to maintain knowledge in your build system about which versions of which compilers support which flags, you might do the same as I suggested in ticket #15 and just ask the compiler if it supports a flag before deciding to use it.
Fixed in 5.0.5
Fixed in 5.0.5