# Configurable in CMAKE\_TOOLCHAIN\_FILE files
**URL:** https://discourse.cmake.org/t/configurable-in-cmake-toolchain-file-files/1122
**Category:** Usage
**Created:** [April 29, 2020, 4:30pm UTC](https://discourse.cmake.org/t/configurable-in-cmake-toolchain-file-files/1122 "2020-04-29T16:30:52Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@Guru\_Gajah](https://discourse.cmake.org/u/Guru_Gajah)
#### Post date: [April 29, 2020, 4:30pm UTC](https://discourse.cmake.org/t/configurable-in-cmake-toolchain-file-files/1122/1 "2020-04-29T16:30:52Z")
Consider having constructs like the following i a CMAKE\_TOOLCHAIN\_FILE:
set(SOME\_VAR “some\_default” CACHE STRING “some text”)
What would be the drawback pitfall with it?
Will cache always work? ccmake?
Would option propagate correctly in add\_subdirectory(…)? Also in all cases including top-levl CMakeLists.txt files induced by add\_subdirectory()
Does order of option given on command-line matter?
BR /G
---
### Author:  [@developer](https://discourse.cmake.org/u/developer)
#### Post date: [April 30, 2020, 5:16pm UTC](https://discourse.cmake.org/t/configurable-in-cmake-toolchain-file-files/1122/2 "2020-04-30T17:16:25Z")
Somebody else feel free to jump in 🙂
This is a helpful resource too, see Cache variables ([https://cliutils.gitlab.io/modern-cmake/chapters/basics/variables.html](https://cliutils.gitlab.io/modern-cmake/chapters/basics/variables.html)).
Setting SOME\_VAR like that will not always set the value in the case that the variable has already been set previously in CMake configuration or it has been passed via command line.
I do believe that variable (option) will populate to sub-directories since the toolchain file is included at the top level (typically on the command line) of the CMake project.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [April 30, 2020, 9:20pm UTC](https://discourse.cmake.org/t/configurable-in-cmake-toolchain-file-files/1122/3 "2020-04-30T21:20:54Z")
> [@Guru\_Gajah](#):
>
> Consider having constructs like the following i a CMAKE\_TOOLCHAIN\_FILE:
>
> set(SOME\_VAR “some\_default” CACHE STRING “some text”)
>
> What would be the drawback pitfall with it?
Because it is a cache variable, it will only set the value of SOME\_VAR if it is not already set. It is not wrong to do so, but usually not the best approach. I tend to only need to set plain variables in toolchain files. These may be used to initialise other cache variables (e.g. setting CMAKE\_CXX\_FLAGS\_INIT in the toolchain file, which is used to provide the initial value for the CMAKE\_CXX\_FLAGS cache variable).
> [@Guru\_Gajah](#):
>
> Will cache always work? ccmake?
Yes, there is no difference between the `cmake` and `ccmake` tools in this case.
> [@Guru\_Gajah](#):
>
> Would option propagate correctly in add\_subdirectory(…)? Also in all cases including top-levl CMakeLists.txt files induced by add\_subdirectory()
The toolchain file is pulled in whenever a new language is enabled. It is as though `include(myToolchainFile.cmake)` is called at the relevant line. That means any variables it sets will remain visible in that directory scope and below. So yes, values will propagate down into `add_subdirectory()` calls. The top level `project()` command is usually where languages will be enabled, but it could also be in other places like where `enable_language()` is called or where `project()` is called against with additional `LANGUAGES`. The file will also be pulled in for `try_compile()` calls, but those are in separate test sub-builds off to the side and won’t affect variables in the main project.
> [@Guru\_Gajah](#):
>
> Does order of option given on command-line matter?
Probably only if you have `-U` options mixed in with `-D` options, but I can’t be sure. You can always do some experiments to find out.