# Using find\_file with an indirected variable name

**URL:** https://discourse.cmake.org/t/using-find-file-with-an-indirected-variable-name/9212
**Category:** Usage
**Created:** [October 17, 2023, 7:52pm UTC](https://discourse.cmake.org/t/using-find-file-with-an-indirected-variable-name/9212 "2023-10-17T19:52:49Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![EosPengwern](https://discourse.cmake.org/user_avatar/discourse.cmake.org/eospengwern/32/3904_2.png) [@EosPengwern](https://discourse.cmake.org/u/EosPengwern)
#### Post date: [October 17, 2023, 7:52pm UTC](https://discourse.cmake.org/t/using-find-file-with-an-indirected-variable-name/9212/1 "2023-10-17T19:52:49Z")

</div>

I’d expect this to work:

```auto
set(releaseLibName "lib${target}_${requiredVersion}_Rel")

find_file(${releaseLibName}
          NAMES lib${target}_${requiredVersion}.${EXTvar}
          PATHS ${MY_PATHS}
          DOC "${target} release library"
          NO_DEFAULT_PATH)

if (EXISTS ${${releaseLibName}})
    message("Found it!)
else()
    message("Not found")
endif()

```

…but it does not; even if the file I’m looking for definitely exists, ${${releaseLibName}} returns nothing.

In the other hand, this works fine:

```auto
find_file(ORDINARY_VARIABLE
          NAMES lib${target}_${requiredVersion}.${EXTvar}
          PATHS ${MY_PATHS}
          DOC "${target} release library"
          NO_DEFAULT_PATH)

if (EXISTS ${ORDINARY_VARIABLE})
    message("Found it!)
else()
    message("Not found")
endif()

```

Is it by design that find\_file doesn’t work when the variable name is itself held in another variable (i.e. double indirection), of is there something subtly wrong with my syntax 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: [October 18, 2023, 7:31pm UTC](https://discourse.cmake.org/t/using-find-file-with-an-indirected-variable-name/9212/2 "2023-10-18T19:31:22Z")

</div>

What happens if you use some quotes?

```cmake
set(releaseLibName "lib${target}_${requiredVersion}_Rel")

find_file("${releaseLibName}"
          NAMES lib${target}_${requiredVersion}.${EXTvar}
          PATHS ${MY_PATHS}
          DOC "${target} release library"
          NO_DEFAULT_PATH)

if (EXISTS "${${releaseLibName}}")
    message("Found it!")
else()
    message("Not found")
endif()

```

---

<div class="post-metadata">

### Author: ![EosPengwern](https://discourse.cmake.org/user_avatar/discourse.cmake.org/eospengwern/32/3904_2.png) [@EosPengwern](https://discourse.cmake.org/u/EosPengwern)
#### Post date: [October 19, 2023, 10:42am UTC](https://discourse.cmake.org/t/using-find-file-with-an-indirected-variable-name/9212/3 "2023-10-19T10:42:05Z")

</div>

I’m fairly sure I tried that, but nothing I tried could get it to work with indirection.

What I did instead was to set CMP0125 to NEW so that I could use an ordinary non-cache variable to receive the path without a new cache variable being created. I could then copy this non-cache variable to another variable with an indirected name.

A lot of my problems in my wider code were caused by not realising that the default behaviour of find\_file was to create a new cache variable, which then took precedence over non-cache variables. so in my example given above, even ORDINARY\_VARIABLE was being created as a new cache variable without me realising.

---

<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: [October 19, 2023, 1:35pm UTC](https://discourse.cmake.org/t/using-find-file-with-an-indirected-variable-name/9212/4 "2023-10-19T13:35:47Z")

</div>

> [@EosPengwern](#):
>
> A lot of my problems in my wider code were caused by not realising that the default behaviour of find\_file was to create a new cache variable, which then took precedence over non-cache variables. so in my example given above, even ORDINARY\_VARIABLE was being created as a new cache variable without me realising.

Ah! Local variables always win over cache variables. The various policies involved here, including CMP0125, stopped these commands from mucking with the local variables. CMP0125 was particularly fun because it would nuke the local variable _if_ the cache variable was of type `UNINITIALIZED` (basically, `-DFOO=bar` rather than `-DFOO:STRING=bar` on the command line) in the process of setting the cache type. If it already had a type, it would leave the local variable alone.