我正在将构建系统从仅使用Visual Studio迁移到cmake . Visual Studio仍然是主要IDE，但Linux是辅助构建目标平台 . 我有许多应用程序之间共享的大量cmake目标（DLL） . 例如，应用程序A可能链接DLL1，DLL2和DLL3，而应用程序B链接DLL1，DLL2和DLL4 . 所有DLL可能依赖于其他DLL，例如DLL1可能链接DLL2 . 实际上，DLL的数量是数百，而应用程序的数量是两位数 . 每个DLL的源代码都位于一个单独的（子）目录中 .

仅使用Visual Studio，这不是问题：我可以为每个应用程序创建一个相对较小的解决方案（.sln），包括每个链接DLL的.vcxproj文件 . DLL是按需构建的，即当它们是当前应用程序所需的时候 . 每个DLL（vcxproj）都只有一个二进制输出目录 . 因此，即使在切换解决方案时，我也只需要构建一次DLL .

迁移到cmake，我面临以下挑战 . 在每个DLL子目录中创建一个CMakeLists.txt很方便，定义相应的cmake目标 . 但是，似乎cmake不支持定义不同cmake项目的多个顶级CMakeLists.txt文件（对应于解决方案，即应用程序） . 首先，我不能将几个CMakeLists.txt保存在一个目录中 . 由于cmake是以目录作为参数而不是单个文件启动的，因此无法更改CMakeLists.txt的名称 . 其次，即使我为每个顶级CMakeLists.txt创建一个单独的文件夹，这些cmake项目也无法共享其二进制构建目录 . 如果我尝试强制执行该操作，则cmake会抛出有关与CMakeLists.txt文件不匹配的缓存的错误 .

理想情况下，我希望目录结构看起来像这样：

binary_build
|- application1
|- application2
|- DLL1
|- DLL2
|- ...

source
|- CMakeLists_application1.txt 
   // define a cmake project, add DLL directories with add_subdirectory()
|- CMakeLists_application2.txt
|- ...
|- DLL1
    |- src
    |- include
    CMakeLists.txt // define a cmake target, but no project
|- DLL2
    |- src
    |- include
    CMakeLists.txt
|- ...

由于上述原因，这是不可能的 . 显然，我可以创建一个包含所有目标（包括应用程序）的单个巨大解决方案，然后只构建我目前感兴趣的目标 . 但是，这非常不方便，因为它使Visual Studio非常慢 . 从一个解决方案中的大约200个VS项目开始，Visual Studio甚至会崩溃 . 我还尝试将顶级构建目录分开并仅共享DLL目标构建目录 . 但是，这会导致不断重新创建和重新构建VS项目（打破以前创建的解决方案，因为VS项目ID会发生变化） .

在cmake项目之间是否有一个优雅的解决方案来共享目标（及其二进制构建目录）？

visual-studio cmake