Windows simplemente no tiene algunos de los conceptos necesarios para permitir que CMake configure su entorno de compilación. Al vincular, Windows buscará en el mismo directorio que el binario y luego buscará los directorios en su RUTA. No hay nada como RPATH, que se usa en la mayoría de las plataformas Unix, para inyectar en otras rutas más apropiadas. Por lo general, las DLL deben instalarse junto con sus archivos binarios, en el mismo directorio.
En mi opinión, la mejor práctica en Windows es colocar las DLL junto a los archivos binarios. CHacer intentos de hacer esto más fácil,
install(TARGETS MyTarget
EXPORT "MyProjectTargets"
RUNTIME DESTINATION "${INSTALL_RUNTIME_DIR}"
LIBRARY DESTINATION "${INSTALL_LIBRARY_DIR}"
ARCHIVE DESTINATION "${INSTALL_ARCHIVE_DIR}")
instalaría archivos DLL en el destino RUNTIME, pero colocaría las bibliotecas en el destino BIBLIOTECA. Esto significa que, por lo general, en los sistemas operativos similares a Unix, lib tiene los objetos compartidos, pero CMake sabe que las DLL son efectivamente en tiempo de ejecución y se irían a la papelera. Esperemos que esto aclare las cosas. Es imposible que CMake/Eclipse realmente mejore tanto, más allá de quizás inyectar directorios adicionales en su RUTA al hacer clic en ejecutar desde Eclipse (no estoy seguro si eso es posible).
Si le preocupa el árbol de compilación, lo siguiente funcionaría bien allí (como se sugiere en los comentarios a continuación):
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/bin")
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/lib")
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/lib")
Si desea permitir que estos se anulen (puede ser útil), también deben protegerse con bloques if (NO var_name).
Sólo una posible respuesta a mi propia pregunta. Creo que en Linux, rpath se usa para identificar las ubicaciones de las bibliotecas dependientes, pero en Windows con mingw no puedo usar el analizador elf y, por lo tanto, no puedo usar rpath.