Windows prostě nemají některé nezbytné koncepty, které by CMake umožnily nastavit vaše prostředí pro sestavení. Při propojování bude Windows hledat ve stejném adresáři jako binární a poté hledat adresáře ve vaší PATH. Neexistuje nic jako RPATH, který se používá na většině unixových platforem, k zavedení jiných vhodnějších cest. Knihovny DLL by obecně měly být instalovány vedle vašich binárních souborů ve stejném adresáři.
Podle mého názoru je nejlepší praxí ve Windows umístit knihovny DLL vedle vašich binárních souborů. CPokuste se to usnadnit,
install(TARGETS MyTarget
EXPORT "MyProjectTargets"
RUNTIME DESTINATION "${INSTALL_RUNTIME_DIR}"
LIBRARY DESTINATION "${INSTALL_LIBRARY_DIR}"
ARCHIVE DESTINATION "${INSTALL_ARCHIVE_DIR}")
by nainstalovat knihovny DLL do cíle RUNTIME, ale umístit knihovny do cíle LIBRARY. To znamená, že na operačních systémech podobných Unixu má lib sdílené objekty, ale CMake ví, že DLL jsou efektivně runtime a šly by do koše. Snad to objasní věci. Je nemožné, aby to CMake/Eclipse skutečně vylepšilo, kromě možná vložení dalších adresářů do vaší PATH při kliknutí na spustit z Eclipse (nejsem si jistý, jestli je to možné).
Pokud se zajímáte o sestavení stromu, pak by zde dobře fungovalo následující (jak je navrženo v komentářích níže):
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")
Pokud chcete povolit jejich přepsání (může být užitečné), měly by být chráněny také bloky if(NOT var_name).
Jen možná odpověď na vlastní otázku. Myslím, že na linuxu se rpath používá k identifikaci umístění závislých knihoven, ale v oknech s mingw nemůžu použít elf parser, a tak nemůžu použít rpath.