I would stick with the original idea of ββusing add_custom_command . However, I would recommend using the add_custom_command(TARGET ...) form rather than add_custom_command(OUTPUT ...) .
The OUTPUT version is designed to use the output file as a source file for another CMake target in the same CMakeLists.txt file. The user command is called when this goal is built (right at the beginning), since the goal requires the file to exist at this point.
In your case, not one goal depends on your file - this is the product of the build process.
If you use add_custom_command(TARGET ...) , this ensures that the command is executed every time the target is rebuilt. Using add_custom_target requires you to keep this in mind if the original target is updated ( test in this case). It also unnecessarily adds to your list of goals - perhaps this is not a problem for a tiny project, but it can be for large projects.
This is how I installed the command:
SET(COPY_TO_PATH custom1) ADD_CUSTOM_COMMAND(TARGET test POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy $<TARGET_FILE:test> ${COPY_TO_PATH} COMMENT "Copying 'test' library to '${COPY_TO_PATH}'")
This adds the command as an event after the test build. As you correctly identified, the names of hardcoding libraries are small; therefore CMake provides "generator expressions" to handle this. The generator expression $<TARGET_FILE:test> resolves the full path of the library created by test , regardless of platform or compiler. Note that generator expressions can only be used in the COMMAND argument; you could not use them in the COMMENT part, for example.
The actual command invokes CMake itself ( ${CMAKE_COMMAND} ) with the -E option on the command line . This provides a cross-platform way to get a copy, since cp not a Windows command. To see all the -E options, run cmake -E help .
source share