Feature Request: Properties on targets which inherit via target_link_libraries rather than directory scope
In define_property() it is possible to make properties which are scoped to targets. It is also possible to specify that they inherit their values by chaining parent scope values when undefined in the current scope (via the INHERIT option). However, the chaining is defined by directory, even for targets. This seems at odds with the targets with dependencies (via target_link_libraries) style encouraged by recent versions of CMake (and described in the CMake Tutorial - see 'Adding Usage Requirements for Library (Step 3)').
It would be great if it was possible to define custom properties on targets which chain via target dependencies (like the INTERFACE_COMPILE_DEFINITIONS etc. properties already do).
Concrete Usage Example: Copying DLLs or Other Runtime Required Files Based on Dependencies During Build Time
The specific use-case I'd like to simplify with this would be to define a custom property called RUNTIME_REQUIREMENTS on targets, or similar, to which I can add paths to any .dlls etc. which I would like to copy via a post build step using the property in a generator expression. This setup would allow the requirements to be specified alongside each individual library with a common copy_runtime_requirements_for_target() method which uses the property to generate the necessary post build copy commands on the top level target.
There have also been several requests for achieving this via existing properties eg. issue 16462 but it seems that there are complications with that approach which would be avoided via the method proposed here.
Another common suggestion when this issue is raised is to use the CMake's Install functionality. This is also not viable for projects with very large codebases including many top level executables as Install requires the full project to be built and installed prior to running any individual app within the project - which is impractical as it takes a long time to do. Also unless you copy the runtime requirements at build time you cannot debug in Visual Studio using the usual build->run cycle expected by most developers as you just get a missing .dll error.
Finally there is a suggestion to add a runtime context to CMake which handles this Issue 19874 which would also potentially be a workable solution if implemented.
I have not found a discussion on this topic which ended with a viable solution being proposed (accepting the restrictions stated above) within CMake as it stands (version 3.17). If there is one I have missed, please add a comment.
An alternative for this specific use case would be to directly implement a RUNTIME_REQUIREMENTS property (See Issue 2047: Feature Request: Explicit Tracking of Runtime Requirements) which behaves as described here and performs the copies for to executable target's binary directory. This would be similar to the RUNTIME_DIRECTORIES suggestion in issue 19874 except it would copy the files next to the executable rather than reference the paths meaning you would be able to run the executable without any special runtime environment wrappers.
The only solutions I can think of using CMake 3.17 are:
- Hard code the runtime requirements in each executable (ie. list them explicitly in post build copy commands). Workable but seems such a shame as CMake has all the information I need to not need to do this!
- Find a way to interrogate the generated executable (using something like Dependencies) to extract them in a post build step - This does not seem like a good idea to me!
- Manually walk the dependency tree in CMake and generate them. This is almost workable though it generates a lot CMake code and CMake complains if you try and read LINK_LIBRARIES on an INTERFACE library during the walk - and I haven't yet worked out how to work around this.
Related Issues/Discussions:
- Handling Runtime Dependencies:
- Generating Transitive Dependency List: