如何以与 VS 解决方案（VS 自动构建依赖项）类似的方式管理自定义库？答案

【问题标题】：How to manage custom libraries in a similar way to VS solutions (where VS builds dependencies automatically)?如何以与 VS 解决方案（VS 自动构建依赖项）类似的方式管理自定义库？
【发布时间】：2018-04-04 15:52:52
【问题描述】：

在 Visual Studio 中，一个“解决方案”可以有多个项目，而且一个项目可以是另一个项目的依赖项。

之所以有用是因为Visual Studio会在你正在构建的项目编译的时候构建依赖。

这可确保您正在编译的依赖二进制文件始终是最新版本。忽略自定义库中正在进行的（而非发布）代码等问题，如何在 CLion 或其他 Linux 开发设置/环境中实现此行为？

我了解正常的工作流程是将库放入/usr/lib/，但是还有其他方法吗？

【问题讨论】：

CMake…………………………
CLion 使用CMake 进行项目管理。我建议你阅读its documentation。
@Someprogrammerdude CMake 不要求您已经构建了依赖项并且只链接到二进制文件吗？
对于 CLion，CMake 系统将生成构建所有源并链接所有依赖项的 makefile。您需要做的就是列出您拥有的目标，列出每个目标的源文件，然后列出每个目标的依赖关系。
@Someprogrammerdude 我知道这对很多人来说可能看起来微不足道，但是您能否使用伪库A、B、C 和D 写一个示例的答案例如，项目A 依赖于库B 和C，而C 本身依赖于D。我了解总体方向，但不了解如何使用 CMake 创建该依赖关系图。

标签： c++ linux development-environment dependency-management clion

【解决方案1】：

使用您在评论中列出的结构，可能是这样的

project(A)

add_executable(A ${SOURCES_FOR_A})
target_link_libraries(A B C D)  # Make A depend on libraries B, C and D

add_library(B STATIC ${SOURCES_FOR_B})
add_library(C STATIC ${SOURCES_FOR_C})
add_library(D STATIC ${SOURCES_FOR_D})

请注意，C 和 D 之间没有特殊的依赖关系，因为静态库通常只是目标文件的简单存档。静态库本身并没有真正链接，您需要在链接可执行文件时提供所有静态库，即使其中任何一个都没有被应用程序直接使用。

如果库是共享的，那就有点不同了：

project(A)

add_executable(A ${SOURCES_FOR_A})
target_link_libraries(A B C)  # Make A depend on libraries B and C

add_library(B SHARED ${SOURCES_FOR_B})

add_library(C SHARED ${SOURCES_FOR_C})
target_link_libraries(C D) # Make C depend on D

add_library(D SHARED ${SOURCES_FOR_D})

共享库是链接的，与可执行目标非常相似。因此目标A 不需要指定对D 的间接依赖，因为它链接到C。

_{[注意：上面显示的 CMake 命令可能不是所需的确切语法和参数。阅读the documentation 了解确切的语法。]}

【讨论】：

谢谢，现在说得通了！