如何以类似于VS解决方案的方式管理自定义库（VS自动生成依赖关系）？(How to manage custom libraries in a similar way to VS solutions (

如何以类似于VS解决方案的方式管理自定义库（VS自动生成依赖关系）？(How to manage custom libraries in a similar way to VS solutions (where VS builds dependencies automatically)?)

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

它之所以有用的原因是因为Visual Studio在编译您正在构建的项目时会构建依赖关系。

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

我知道正常的工作流程是将库放到/usr/lib/但是还有其他方法吗？

In Visual Studio a "solution" can have multiple projects, further a project can be a dependency of another project.

The reason why it is useful is because Visual Studio builds the dependencies when the project you are building is compiled.

This ensures that the dependency binary you are compiling with is always the most up to date version. Ignoring problems such as work in progress (and not release) code in the custom library, how can this behaviour be achieved in CLion or another Linux development setup/environment?

I understand that the normal workflow is to put the libraries into /usr/lib/ however is there another approach?

最满意答案

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

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命令可能不是所需的确切语法和参数。 阅读文档以获取确切的语法。]}

Using the structure you laid out in your comment, it could be something like this

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

Note that there is no special dependencies between C and D, since static libraries are often nothing more than simple archives of object files. Static libraries are not really linked themselves, you need to provide all static libraries when linking the executable, even if any of them is not used directly by the application.

If the libraries are shared then it's a little different:

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

Shared libraries are linked and very similar to executable targets. Therefore the target A doesn't need to specify the indirect dependency on D, since it's linked into C.

_{[Note: The CMake commands shown above might not the exact syntax and arguments needed. Read the documentation for the exact syntax.]}