# Effect of force overwriting variables
**URL:** https://discourse.cmake.org/t/effect-of-force-overwriting-variables/3207
**Category:** Code
**Created:** [April 24, 2021, 12:22pm UTC](https://discourse.cmake.org/t/effect-of-force-overwriting-variables/3207 "2021-04-24T12:22:43Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@Leon0402](https://discourse.cmake.org/u/Leon0402)
#### Post date: [April 24, 2021, 12:22pm UTC](https://discourse.cmake.org/t/effect-of-force-overwriting-variables/3207/1 "2021-04-24T12:22:43Z")
Hi everyone,
in my project I include a dependency with FetchContent with such a line in it:
```auto
set(BUILD_TESTING OFF CACHE INTERNAL "" FORCE)
```
`BUILD_TESTING` is a variable declared by CTest as far as I understood it. And with the FORCE option you cann override it’s value.
The problem is that I can’t set it via the command line anymore I think.
So I wonder two things:
- Is it wrong that the author has such a line in it’s code? Can I do anything against it?
- How can I set BUILD\_TESTING to False for my dependencies, but not for my project. I fetch all dependencies in a different scope, so with a normal variable, I can just set it there and it has no effect on other things. But with CACHE Variables the story is different, right? Can I set a cache variable with scope?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [April 26, 2021, 12:34pm UTC](https://discourse.cmake.org/t/effect-of-force-overwriting-variables/3207/2 "2021-04-26T12:34:57Z")
> [@Leon0402](#):
>
> Is it wrong that the author has such a line in it’s code? Can I do anything against it?
Yes. Forcing end-user variables like this is not the way to do it. AFAIK, the only way around it is to set a local variable, but this probably has other oddities associated with it.
> [@Leon0402](#):
>
> How can I set BUILD\_TESTING to False for my dependencies, but not for my project.
Just set it to `OFF` as a local variable. Local variables “win” over cache variables, so when subprojects look it up, they’ll see `OFF`, but the cache will stay the same.
> [@Leon0402](#):
>
> But with CACHE Variables the story is different, right? Can I set a cache variable with scope?
CACHE variables always have global scope.
---
### Author:  [@Leon0402](https://discourse.cmake.org/u/Leon0402)
#### Post date: [April 28, 2021, 12:57pm UTC](https://discourse.cmake.org/t/effect-of-force-overwriting-variables/3207/3 "2021-04-28T12:57:27Z")
Thanks for the responses, I patched the lib, but it still don’t works because on of their dependencies - curl.
I could write a small sample, which shows the problem:
```auto
include(CMakeDependentOption)
message(STATUS "Before" ${BUILD_TESTING})
# set(BUILD_TESTING OFF)
cmake_dependent_option(BUILD_TESTING "" ON "" OFF)
message(STATUS "After" ${BUILD_TESTING})
```
```auto
include_subdirectory("whatever file the above is in")
message(STATUS "Paren Scope After" ${BUILD_TESTING})
```
The first message and the last message should always be true. But in fact they are not if both these are set at the same time:
```auto
set(BUILD_TESTING OFF)
cmake_dependent_option(BUILD_TESTING "" ON "" OFF)
```
Is this a bug or what is happening here?
In general I wonder: What can I do about all this? As a CMake User I often feel like I have no control with FetchContent. The library authors can do thing like force caching variables and there is nothing I can do about it (except nicely asking that they don’t do this).
Can CMake add possibilities for me to fix the libraries from my project? For example unforcing a force cache variable perhaps?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [April 28, 2021, 1:03pm UTC](https://discourse.cmake.org/t/effect-of-force-overwriting-variables/3207/4 "2021-04-28T13:03:51Z")
Is there a difference between the first and second configure run? If so, [this issue](https://gitlab.kitware.com/cmake/cmake/-/issues/22038) should resolve this problem once and for all.
> [@Leon0402](#):
>
> As a CMake User I often feel like I have no control with FetchContent.
I know people want to use arbitrary projects with FetchContent and control things, but in my experience, if the project doesn’t _support_ being a subproject of another, it’s usually best to just patch the thing (usually skipping cache variables and just setting local values instead). I don’t believe `FetchContent` can fix all the embeddability problems that arise with projects in the wild. Personally, I think the effort would be better spent on enshrining better behaviors such as:
- using `GNUInstallDirs`
- properly exporting targets
- not using the top-level `PROJECT_` and `SOURCE_DIR` variables
- other best practices which consider the embedding use case
Of course, to _actually_ be viable, mangling needs to be supported in-library (it’s the hairiest part of the vendoring process used in VTK and ParaView), but that’s not exactly the easiest thing to support. With Git these days, it’s easy enough to track a fork and rebase patches onto new releases as things progress that I think it’s still a better solution than `FetchContent` using vanilla upstream sources.
---
### Author:  [@Leon0402](https://discourse.cmake.org/u/Leon0402)
#### Post date: [April 28, 2021, 1:21pm UTC](https://discourse.cmake.org/t/effect-of-force-overwriting-variables/3207/5 "2021-04-28T13:21:27Z")
> [@ben.boeckel](#):
>
> Is there a difference between the first and second configure run? If so, [this issue](https://gitlab.kitware.com/cmake/cmake/-/issues/22038) should resolve this problem once and for all.
There is no difference. It’s always ON - OFF - ON.
What does that command actually (supposed to behave like). Is cmake\_dependent\_option like option(), like set(CACHE), like set(CACHE FORCE), like set() or something completly new or different.
Btw. these things work:
```auto
include(CMakeDependentOption)
message(STATUS "Before !!!" ${BUILD_TESTING})
set(BUILD_TESTING ON)
cmake_dependent_option(BUILD_TESTING "" ON "" OFF)
message(STATUS "After !!! " ${BUILD_TESTING})
```
→ Doesn’t affect parent scope
Neither is the order in cmake\_depent\_option() relevant.
Only this fails:
```auto
include(CMakeDependentOption)
message(STATUS "Before !!!" ${BUILD_TESTING})
set(BUILD_TESTING OFF)
cmake_dependent_option(BUILD_TESTING "" "" "" "")
message(STATUS "After !!! " ${BUILD_TESTING})
```
So setting the variables locally to OFF and calling cmake\_depenent\_option with anything (well the variable name has to be BUILD\_TESTING, but except that)
> [@ben.boeckel](#):
>
> if the project doesn’t _support_ being a subproject of another
I think the problem is that a lot of people don’t understand CMake correctly or fully. Can’t blame anyone here, there are some quite complicated things in cmake (variable behaviour is one of them).
The library I use fully supports being a subproject, except the fact that the library did some mistake and perhaps the library this library depends on as well (or cmake has a bug).
Sometimes it would be just nice to some tools to fix common problems.
Correct me if I’m wrong, but using the build-in Variables or rely on them like “BUILD\_TESTING” or “BUILD\_SHARED\_LIBS” is actually recommended. Because it’s consistent and it’s always clear how you disable the tests for example.
But in such situations people don’t just fix the library or don’t use it all. They just use their own variable called “MYPROJECT\_BUILD\_TESTING”. Issue fixed for them. But that leads to cmake code being really inconsistent, which isn’t the goal I assume.
---
### Author:  [@Leon0402](https://discourse.cmake.org/u/Leon0402)
#### Post date: [July 18, 2021, 2:57pm UTC](https://discourse.cmake.org/t/effect-of-force-overwriting-variables/3207/6 "2021-07-18T14:57:12Z")
Any updates here @ben.boeckel?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [July 18, 2021, 7:52pm UTC](https://discourse.cmake.org/t/effect-of-force-overwriting-variables/3207/7 "2021-07-18T19:52:24Z")
I don’t have any, though now that CMP0125 and CMP0126 are out; maybe it helps here?
---
### Author:  [@Leon0402](https://discourse.cmake.org/u/Leon0402)
#### Post date: [July 24, 2021, 9:14am UTC](https://discourse.cmake.org/t/effect-of-force-overwriting-variables/3207/8 "2021-07-24T09:14:08Z")
I think these didn’t help. Should I open an issue over on gitlab, so this is tracked?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [July 24, 2021, 11:45pm UTC](https://discourse.cmake.org/t/effect-of-force-overwriting-variables/3207/9 "2021-07-24T23:45:40Z")
Yeah, an issue can’t hurt.
---
### Author:  [@Leon0402](https://discourse.cmake.org/u/Leon0402)
#### Post date: [November 13, 2021, 3:23pm UTC](https://discourse.cmake.org/t/effect-of-force-overwriting-variables/3207/10 "2021-11-13T15:23:35Z")
Done: [https://gitlab.kitware.com/cmake/cmake/-/issues/22909](https://gitlab.kitware.com/cmake/cmake/-/issues/22909)
Sorry took a while