# Add CMAKE\_ prefix for BUILD\_SHARED\_LIBS
**URL:** https://discourse.cmake.org/t/add-cmake-prefix-for-build-shared-libs/15078
**Category:** Development
**Created:** [August 20, 2025, 2:04pm UTC](https://discourse.cmake.org/t/add-cmake-prefix-for-build-shared-libs/15078 "2025-08-20T14:04:15Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@nickvdbroeck](https://discourse.cmake.org/u/nickvdbroeck)
#### Post date: [August 20, 2025, 2:04pm UTC](https://discourse.cmake.org/t/add-cmake-prefix-for-build-shared-libs/15078/1 "2025-08-20T14:04:15Z")
Just a suggestion for (what I think is an improvement) in cmake.
The options [`BUILD_SHARED_LIBS`](https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html) 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).
If you check the list here: [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html#variables-that-change-behavior](https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html#variables-that-change-behavior) it is very clear that those two variables are not following the same pattern as the other variables.
(Of course I understand that some backwards compatibility is in order)
---
### Author:  [@LegalizeAdulthood](https://discourse.cmake.org/u/LegalizeAdulthood)
#### Post date: [August 20, 2025, 3:18pm UTC](https://discourse.cmake.org/t/add-cmake-prefix-for-build-shared-libs/15078/2 "2025-08-20T15:18:02Z")
> [@nickvdbroeck](#):
>
> (Of course I understand that some backwards compatibility is in order)
Yes, I think this would imply that a policy would also need to be added.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [August 20, 2025, 3:45pm UTC](https://discourse.cmake.org/t/add-cmake-prefix-for-build-shared-libs/15078/3 "2025-08-20T15:45:46Z")
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.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [August 20, 2025, 10:35pm UTC](https://discourse.cmake.org/t/add-cmake-prefix-for-build-shared-libs/15078/4 "2025-08-20T22:35:53Z")
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.
---
### Author:  [@nickvdbroeck](https://discourse.cmake.org/u/nickvdbroeck)
#### Post date: [August 21, 2025, 9:12am UTC](https://discourse.cmake.org/t/add-cmake-prefix-for-build-shared-libs/15078/5 "2025-08-21T09:12:52Z")
@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.