Windows 上の Cmake は共有ライブラリ パスを追加しません (Linux で動作します)

Windows には、CMake がビルド環境をセットアップできるようにするために必要な概念がいくつかありません。 Windows をリンクすると、バイナリと同じディレクトリが検索され、PATH 内のディレクトリが検索されます。ほとんどの Unix プラットフォームで使用されている RPATH のように、他のより適切なパスに挿入するものはありません。 DLL は通常、バイナリと一緒に同じディレクトリにインストールする必要があります。

私の意見では、Windows でのベスト プラクティスは、バイナリの隣に DLL を配置することです。 CMake はこれを簡単にしようとします、

install(TARGETS MyTarget
  EXPORT "MyProjectTargets"
  RUNTIME DESTINATION "${INSTALL_RUNTIME_DIR}"
  LIBRARY DESTINATION "${INSTALL_LIBRARY_DIR}"
  ARCHIVE DESTINATION "${INSTALL_ARCHIVE_DIR}")

DLL は RUNTIME 宛先にインストールされますが、ライブラリは LIBRARY 宛先に配置されます。これは、通常、Unix ライクな OS では lib に共有オブジェクトがあることを意味しますが、CMake は DLL が実質的にランタイムであり、bin に入れられることを認識しています。うまくいけば、これで物事が明確になります。 Eclipse から [実行] をクリックしたときに追加のディレクトリを PATH に挿入する以外に、CMake/Eclipse がこれほど改善することは不可能です (それが可能かどうかはわかりません)。

ビルド ツリーに関心がある場合は、次の方法で問題なく動作します (以下のコメントで提案されているように):

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")

これらをオーバーライドできるようにしたい場合 (便利な場合があります)、if(NOT var_name) ブロックでも保護する必要があります。

私自身の質問に対する可能な答えです。 Linux では依存ライブラリの場所を識別するために rpath が使用されていると思いますが、mingw を使用する Windows では elf パーサーを使用できないため、rpath を使用できません。