# Feature Request: list() commands should write to CACHE variables

**URL:** https://discourse.cmake.org/t/feature-request-list-commands-should-write-to-cache-variables/4685
**Category:** Development
**Created:** [December 16, 2021, 11:15am UTC](https://discourse.cmake.org/t/feature-request-list-commands-should-write-to-cache-variables/4685 "2021-12-16T11:15:58Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![KUGA2](https://discourse.cmake.org/user_avatar/discourse.cmake.org/kuga2/32/4968_2.png) [@KUGA2](https://discourse.cmake.org/u/KUGA2)
#### Post date: [December 16, 2021, 11:15am UTC](https://discourse.cmake.org/t/feature-request-list-commands-should-write-to-cache-variables/4685/1 "2021-12-16T11:15:59Z")

</div>

Today we stumbled upon an error in our CMake codebase that comes from  
[CMP0126](https://cmake.org/cmake/help/v3.22/policy/CMP0126.html#policy:CMP0126) = NEW. It was very hard to find, we were sure that there is no normal variable.  
We located the culprit in list() on CACHE variables. This little detail is important here:

> Similar to the [`set()`](https://cmake.org/cmake/help/latest/command/set.html#command:set) command, the LIST command creates new variable values in the current scope, even if the list itself is actually defined in a parent scope.

I think list should write to the variable it reads from. If it reads from a cache variable (explicitly `CACHE{cvar}` or implicitly `cvar` because no normal variable is defined), it should also write to this.

This feature probably also needs a policy flag, because it might break old codebases.

Since changing (non INTERNAL) cache variables needs FORCE, you might also add this the list functions.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [December 16, 2021, 5:40pm UTC](https://discourse.cmake.org/t/feature-request-list-commands-should-write-to-cache-variables/4685/2 "2021-12-16T17:40:49Z")

</div>

I don’t think modifying the cache should be so easy. It is _far_ too easy to end up with states where you need to double-configure to get something to happen (or not happen) from such things. Most cases for `INTERNAL` cache variables are better served by global properties instead. If you really need to operate on cache variables directly, for the usual `APPEND` case, you have:

```cmake
set_property(CACHE cache_var APPEND PROPERTY VALUE appended)

```

---

<div class="post-metadata">

### Author: ![KUGA2](https://discourse.cmake.org/user_avatar/discourse.cmake.org/kuga2/32/4968_2.png) [@KUGA2](https://discourse.cmake.org/u/KUGA2)
#### Post date: [January 3, 2022, 8:49am UTC](https://discourse.cmake.org/t/feature-request-list-commands-should-write-to-cache-variables/4685/3 "2022-01-03T08:49:19Z")

</div>

They maybe you should simply forbid (or issue a warning) when using “writing” `list` function on cache variables. Creating a new non-cache variable is probably never what you want here.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [January 3, 2022, 4:09pm UTC](https://discourse.cmake.org/t/feature-request-list-commands-should-write-to-cache-variables/4685/4 "2022-01-03T16:09:35Z")

</div>

The thing is that users can pass in whatever cache variables they want and “clobber” local variables. I don’t think such hard errors is a nice behavior either.