Just a suggestion for (what I think is an improvement) in cmake.
The options BUILD_SHARED_LIBS and BUILD_TESTING are both missing a CMAKE_ prefix in my opinion.
Having CMAKE_BUILD_SHARED_LIBS would be more consistent with the other cmake variables. Also it makes it clear that it is a cmake thing and not a custom variable. We have been starting to add our own prefix to our own variables to avoid name clashes and when I first came accross BUILD_SHARED_LIBS I added our prefix before it (even though I was the one that introduced the variable in the first place).
For reference, BUILD_SHARED_LIBS and BUILD_TESTING are two of the oldest settings we have. At the time of their introduction the CMAKE_ prefix was not well established. IIRC they were meant to look like project-level settings that happen to be available to every project.
If we were starting from scratch we’d probably go with a CMAKE_ prefix. However, the existing names are so widespread I think it would do more harm than good to try changing it now, even with a policy.
It’s also worth pointing out that BUILD_TESTING is only applicable if you’re doing include(CTest). All it does is conditionally call enable_testing(). I recommend projects just call enable_testing() directly and forget about BUILD_TESTING altogether. You only need to include(CTest) if you’re going to run dashboard tests, which the majority of CMake projects don’t actually do, in my experience.
@craig.scott, yes indeed, we don’t use BUILD_TESTING, only BUILD_SHARED_LIBS, but I was searching a bit in the documentation on the rationale behind the absent CMAKE_ prefix and found both of these in the same boat. And yes, we are using dashboard tests to communicate with CDash, but I can’t say that is a pleasant experience. Just CTest with presets works a lot better.
@brad.king, I assumed the reasons were historic in nature (they usually are). Still, I would consider to define both variables with and without prefix. In the manual you can indicated that with prefix is the preferred way and without is only there for backwards compatibility. That is a small fix to do code wise. Fast forward 5 years with this and your concern about breaking projects will be less. But of course it all depends on the intention. So then you add the warning. Another 5 years later you can safely remove the variable. If your feeling as a developer is that the CMAKE_ prefix should be there, then as a fellow developer I can only suggest you to take action now. If you don’t take action, the number of projects using BUILD_SHARED_LIBS is only going to grow, so it will never get easier to add the prefix than it is now.
But I can imagine that there are bigger things to fix and work on. So don’t worry, I am not pushing. I just want to help make CMake even better by pointing out an inconsistency I came across. Kudo’s for the CMake team on the great product it currently is.