To be really pedantic it could be coupled to an install variant which is made default only on specific platforms, but I don't see any problems making it unconditional. Given KitWare's attitude I think that shunting the whole policy is an acceptable approach for MacPorts. I still set the policy to NEW on the cmake commandline (in my still-pending modified cmake 1.1 PG) and together with the patch I've been able to build cmake-based projects with any compiler I've thrown at them. It removes the whole taking-into-consideration of the CMP25 policy. Mojca is right in her assessment of the problematic part, I'll be attaching a port:cmake patch that seems to have "resolved" the problem for me. Hmmm, evidently I forgot about this ticket.Ī patch is being tested for the Qt cmake module that triggers the issue and which got me acquainted with it. My suggestion would be to come up with a set of proper patches for these files and submit the patches upstream. opt/local/share/cmake-3.8/Modules/Platform/Darwin-Clang-CXX.cmake opt/local/share/cmake-3.8/Modules/Platform/Darwin-AppleClang-CXX.cmake opt/local/share/cmake-3.8/Modules/Platform/Darwin-AppleClang-C.cmake opt/local/share/cmake-3.8/Modules/Compiler/Clang.cmake opt/local/share/cmake-3.8/Modules/Compiler/Clang-DetermineCompilerInternal.cmake opt/local/share/cmake-3.8/Modules/Compiler/Clang-DetermineCompiler.cmake opt/local/share/cmake-3.8/Modules/Compiler/Clang-CXX.cmake opt/local/share/cmake-3.8/Modules/Compiler/Clang-CXX-TestableFeatures.cmake opt/local/share/cmake-3.8/Modules/Compiler/Clang-CXX-FeatureTests.cmake opt/local/share/cmake-3.8/Modules/Compiler/Clang-C.cmake opt/local/share/cmake-3.8/Modules/Compiler/Clang-C-FeatureTests.cmake opt/local/share/cmake-3.8/Modules/Compiler/Clang-ASM.cmake opt/local/share/cmake-3.8/Modules/Compiler/AppleClang-DetermineCompiler.cmake opt/local/share/cmake-3.8/Modules/Compiler/AppleClang-CXX.cmake opt/local/share/cmake-3.8/Modules/Compiler/AppleClang-CXX-FeatureTests.cmake opt/local/share/cmake-3.8/Modules/Compiler/AppleClang-C.cmake opt/local/share/cmake-3.8/Modules/Compiler/AppleClang-C-FeatureTests.cmake opt/local/share/cmake-3.8/Modules/Compiler/AppleClang-ASM.cmake Maybe there's a lag in updating their mail archive. The discussion thread subject is COMPILE_FEATURES, Mac and non-Apple clang versions. The discussion thread subject is COMPILE_FEATURES, Mac and non-Apple clang versions.īugs are reported on their mailing list, and I'm not yet seeing an archived version. I can't: bugs are reported on their mailing list, and I'm not yet seeing an archived version. If you've done that already, please provide a link to the bug report. The effect of that will be that OS X is not treated any different than standard Unix (rather, anything not Win32) in that no more difference will be made between Apple clang, macports-clang or any other home brewn clang ) If we agree on that we can also just remove the policy 25 checks in Clang-C.cmake and Clang-CXX.cmake. That is something that can be undone with the usual methods, but a priori it only has the effect that cmake will accept any clang compiler on Mac, not just one identifying as AppleClang. So I'll stick to setting -DCMAKE_POLICY_DEFAULT_CMP0025=NEW in configure.pre_args. But that point is moot: it seems one cannot select a minimum version that way. Hah, that's you and Qt's Thiago who agree that CMake should be doing something about this, and as I expected the consensus among the CMake devs (in the form of a single person) is that there is no bug, projects just have to do the right thing, know all the little details on all platforms where they might be deployed, etc.Įvidently I would have made either the minimum version configurable, or else the whole init.cache thing optional.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |