当 lib 文件夹中同时存在静态和共享 C++ 库时，仅链接静态库答案

【问题标题】：Link only static library when both static and shared C++ libraries are present in lib folder当 lib 文件夹中同时存在静态和共享 C++ 库时，仅链接静态库
【发布时间】：2018-04-11 02:38:00
【问题描述】：

我使用 conan 作为依赖管理器，使用 cmake 作为构建工具。我有一些预先构建的第三方库，它们在 lib 文件夹（ .a 和 .so 文件）中有共享库和静态库。我的计划是从那些预先构建的库中创建柯南包，并使用它们来构建应用程序

当我在构建应用程序时尝试链接库时，默认情况下它会链接共享库。但我想将静态库用于特定应用程序。

解决问题的一种方法是为静态库和共享库创建两个单独的 conan 包，并将所需的静态包包含在 conanfile 中，但这会导致 Artifact 管理的冗余（相同的头文件将出现在多个包中)。

是否有更好的方法通过对 conanfile.py 或 CMakeLists.txt 进行任何更改，以便我可以链接静态库而不是共享库，即使相同的 lib 文件中存在类似的共享库（例如 libX .a 和 libX.so 都在同一个 lib 文件夹中）？

【问题讨论】：

标签： c++ build cmake conan

【解决方案1】：

解决问题的一种方法是为静态库和共享库创建两个单独的 conan 包，并将所需的静态包包含在 conanfile 中，但这会导致 Artifact 管理的冗余（相同的头文件将存在于多个包中)。

这是我的第一个建议。但不是作为两个单独的包，而是使用与options={"shared": [True, False]} 相同的包配方，并使其生成2个不同的包二进制文件（但对于同一个包。除非你有一个包含数千个头文件的庞大库（即使如此），对下载时间和磁盘空间的影响非常小。如果必须手动创建或安装软件包可能会出现问题，但由于一切都是自动的，您不会注意到。如果生成了一些 config.h（不同平台的配置不同或静态/共享），或者不同平台有不同的头文件，典型的 "header_win.h"，这种方法的优点是更容易将来维护和 "header_linux.h"，可以通过 conan 完全自动化，从而拥有一个对消费者透明的 "header.h"。

如果您仍然不想有这种重复，可以有不同的方法：

首先，您可以制作一个仅包含标头的 "PkgHeaders" 包，即 "Pkg" 包中的 required，它将仅包含二进制文件（共享或静态）

另一种方法：您可以使“Pkg”包同时包含静态和共享版本。它类似于here in the docs 解释的发布/调试多配置包。这个想法是该软件包没有shared 选项。它将创建和打包两者。 package_info() 方法将为每个声明不同的变量，例如

 def package_info(self):
     self.cpp_info.shared.libs = ["libX.so"]
     self.cpp_info.static.libs = ["libX.a"]

这会在生成的conanbuildinfo.cmake中生成不同的CMake变量

set(CONAN_LIBS_SHARED libX.so ${CONAN_LIBS_SHARED})
set(CONAN_LIBS_STATIC libX.a ${CONAN_LIBS_STATIC})

但是请注意，这些变量不会在消费者中自动使用，但您必须明确决定使用哪一个。

所以增加的复杂性是不值得的。除非您的库有数百 MB 的标头，否则我肯定会采用第一种方法。

【讨论】：

嗨 drodri，非常感谢您的建议。但是，正如我所提到的，这是一个预先构建的库。我们所能做的就是为它创建柯南包。在这种情况下，你会怎么看？
还是一样。即使您没有build() 方法，package_info() 的规则仍然适用。您可以使用conan export-pkg 非常轻松地使用选项shared=True, False 为同一个包创建2 个包二进制文件。上面的所有讨论都适用，只是你没有build() 方法并使用export-pkg 而不是create。不要犹豫，也可以通过github.com/conan-io/conan/issues 进行更好的讨论。
看起来cpp_info.shared.libs 和cpp_info.static.libs 已经不存在了。