CMake usage philosophy - between build and install, what is the good way ?

Hello everyone,
I’m trying to manage a very old monolythic project which contains either static libs or dynamic (around 98) and a set of exe (around 25). I don’t want to break all the work done for years, so I can’t explode all those projects in mini repos …
So here are my questions :

1 - On a windows environment, what is the CMake install purpose ? Is there a good reason to keep an unix way of thinking (like installing all my exes/dlls in the same bin folder, the static libs in a lib folder…) ? Or is the installation step (for Windows only!) have to create a folder for each project and install dependancies in order to make the exe work without any intervention ?

2 - Since CMake 3.21, there is a very useful expression : TARGET_RUNTIME_DLLS but some of my projects uses a “plugin” pattern and those plugins are not linked to the exe. Is there an elegant way to copy those plugins at the POST_BUILD step ?

Thank you,

An install untangles the results of the build from the build itself. Headers are collected in one place, for example, instead of being split between the source and build tree based on whether it is generated or not. Test libraries and executables also get left behind.

Installs are also able to be relocated (moved as a whole to another directory) unlike builds which are usually very “rooted” to where they were built.

file(GET_RUNTIME_DEPENDENCIES) could probably help here. But plugins are “leaves” just like executables and you can use $<TARGET_RUNTIME_DLLS> on them as well AFAIK.

1 Like

Thank you very much @ben.boeckel for this answer.

It’s very helpful.
Do you think it’s a good idea to create, in my project, a CMake function called find_plugin which check if the plugin name exists, then add the dependency (because the code of the plugin is inside the same repo and the same top cmake) and finally, with a add_custom_command at POST_BUILD time, copy the plugin and its runtime dlls ? Is that compatible with Modern CMake ?


That could work, but I’m sure there are details that need worked out. Qt has some logic around its plugins that might be useful to look at. @craig.scott may know more.