# Making it the librarys responsibility to ensure shared objects are copied?

**URL:** https://discourse.cmake.org/t/making-it-the-librarys-responsibility-to-ensure-shared-objects-are-copied/7412
**Category:** Code
**Created:** [February 6, 2023, 8:24pm UTC](https://discourse.cmake.org/t/making-it-the-librarys-responsibility-to-ensure-shared-objects-are-copied/7412 "2023-02-06T20:24:35Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![kfsone](https://discourse.cmake.org/user_avatar/discourse.cmake.org/kfsone/32/1880_2.png) [@kfsone](https://discourse.cmake.org/u/kfsone)
#### Post date: [February 6, 2023, 8:24pm UTC](https://discourse.cmake.org/t/making-it-the-librarys-responsibility-to-ensure-shared-objects-are-copied/7412/1 "2023-02-06T20:24:35Z")

</div>

Before I write a proposal, I wanted to check my facts on how so/dylib/dll copy requirements are _supposed_ to be stipulated in current CMake.

_Firstly_ this is separate to the _install_ concern: putting everything into the build folder can be essential to testing/debugging.

s.o, and bots like copilot/chatgpt have a few stock solutions to ensuring that DLLs etc get copied to executable output directories. Hope the executable remembers to add\_custom\_command with generator expressions; build up a global with a list of dynamics and hope the executable remembers to add\_custom\_command with it; or add\_custom\_command at the shared target, wrap in a function and have your consumers invoke that, repeat until executable.

In each case, you have to hope nobody downstream forgets to do a post-build step.

Many of the “how to build a linked library” cmake examples deliberately (or unknowingly) avoid this issue by having both exe and dylib in the same directory. I made a simple separation-of-concerns example here: [GitHub - kfsone/cmake-dll: Demonstrate how to ensure your DLL arrives with your binary](https://github.com/kfsone/cmake-dll)

Is this understanding still accurate?