# Copy dll's to runtime\_output\_directory via Imported\_Location property?

**URL:** https://discourse.cmake.org/t/copy-dlls-to-runtime-output-directory-via-imported-location-property/1544
**Category:** Code
**Tags:** os:windows
**Created:** [July 10, 2020, 10:34pm UTC](https://discourse.cmake.org/t/copy-dlls-to-runtime-output-directory-via-imported-location-property/1544 "2020-07-10T22:34:52Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![craffael](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craffael/32/951_2.png) [@craffael](https://discourse.cmake.org/u/craffael)
#### Post date: [July 10, 2020, 10:34pm UTC](https://discourse.cmake.org/t/copy-dlls-to-runtime-output-directory-via-imported-location-property/1544/1 "2020-07-10T22:34:52Z")

</div>

Lets say I have two shared Libraries A, B and an Executable E.  
E depends on B and B depends on A: E -\> B -\> A

Now assume that A and B are imported shared library targets that have their `IMPORTED_LOCATION` properly set. Is it somehow possible to copy the dll’s, whose paths are saved in the `IMPORTED_LOCATION` target properties of A and B, to the output directory of E?

Or do I have to retreat to using `file(GET_RUNTIME_DEPENDENCIES) ` to solve this problem? The difficulty with `file(GET_RUNTIME_DEPENDENCIES) ` is that I’m using hunter package manager to retrieve A and B, so the corresponding dll’s are saved in quite random locations…

---

<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: [November 11, 2020, 5:12pm UTC](https://discourse.cmake.org/t/copy-dlls-to-runtime-output-directory-via-imported-location-property/1544/2 "2020-11-11T17:12:24Z")

</div>

`IMPORTED_LOCATION` is just the location of the linkable `.lib` file, not the `.dll` file. `file(GET_RUNTIME_DEPENDENCIES)` is indeed what I would do here.

---

<div class="post-metadata">

### Author: ![Angew](https://discourse.cmake.org/user_avatar/discourse.cmake.org/angew/32/229_2.png) [@Angew](https://discourse.cmake.org/u/Angew)
#### Post date: [November 12, 2020, 7:06am UTC](https://discourse.cmake.org/t/copy-dlls-to-runtime-output-directory-via-imported-location-property/1544/3 "2020-11-12T07:06:02Z")

</div>

I always thought that with an imported shared library on a DLL platform, `IMPORTED_LOCATION` was supposed to refer to the `.dll` and `IMPORTED_IMPLIB` would point to the `.lib`. I have it set up this way in several projects, and it works. The docs seem to support this too.

---

<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: [November 12, 2020, 12:24pm UTC](https://discourse.cmake.org/t/copy-dlls-to-runtime-output-directory-via-imported-location-property/1544/4 "2020-11-12T12:24:07Z")

</div>

Oh right, I forget that all the time 😕 . You could use genexes to extract the information into a script you write out during cmake time I suppose.

---

<div class="post-metadata">

### Author: ![craffael](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craffael/32/951_2.png) [@craffael](https://discourse.cmake.org/u/craffael)
#### Post date: [November 16, 2020, 3:49pm UTC](https://discourse.cmake.org/t/copy-dlls-to-runtime-output-directory-via-imported-location-property/1544/5 "2020-11-16T15:49:09Z")

</div>

Is there a Generator Expression that contains the path to the dll of an imported target?

---

<div class="post-metadata">

### Author: ![Angew](https://discourse.cmake.org/user_avatar/discourse.cmake.org/angew/32/229_2.png) [@Angew](https://discourse.cmake.org/u/Angew)
#### Post date: [November 16, 2020, 3:54pm UTC](https://discourse.cmake.org/t/copy-dlls-to-runtime-output-directory-via-imported-location-property/1544/6 "2020-11-16T15:54:21Z")

</div>

`$<TARGET_FILE:tgt>` works for me, as does `$<TARGET_PROPERTY:tgt,IMPORTED_LOCATION>`, but the former probably plays nicer with configurations.
