问题描述
这个问题可能部分重复，例如this question，但更多的是关于如果有更好的解决方案的话是什么。由于此问题结束时相当长，我用"；+q+标记了特定问题。 我有这样的情况，我写了一个小库B，它依赖于其他一些大型项目A拆分成许多库A1, A2, ..., An，我的库有一些依赖于这些库，另一些不依赖于这些库。做正确的链接有点麻烦。这个库开始被其他人使用，我想避免每个人都经历这个糟糕的链接过程，即我想将A的所有外部库编译成我的B。假设A是完全外部的，即我没有办法重新编译A(在这种情况下，我可以重新编译，但它很复杂，我想知道我不知道的情况下的选项)。
我想这一定是一件非常标准的事情，我已经使用过其他流行的库，并且从来不需要链接它们过渡依赖的所有其他库。？所以我开始寻找解决方案，虽然我找到了有效的解决方案，但大多数解决方案看起来都很混乱，我想知道这是不是真的做到了，或者是否有什么惯用的方法来解决这个问题。
为了避免在需要不同情况时出现更多最终令人头疼的问题，我希望考虑静态/共享库的所有组合，即
- A和B为静态
- A是静态的，B是共享的
- A是共享的，B是静态的
- A和B共享
要给出一些代码设置的MWE(CMakeLists.txt文件中的变量LIB1_ROOT和LIB2_ROOT分别是A/和B/)：
A/Include/lib1.hh
struct Lib1 { void run() const; };
A/src/lib1.cc
#include <iostream>
#include <lib1.hh>
void Lib1::run() const { std::cout << "Hello from lib1
"; }
A/CMakeLists.txt
cmake_minimum_required(VERSION 3.14)
project(A)
include_directories(include)
add_library(lib1 src/lib1.cc)
install(TARGETS lib1 DESTINATION "${CMAKE_CURRENT_SOURCE_DIR}/lib")
B/Include/lib2.hh
class Lib2 {
class Implementation;
Implementation* impl;
public:
Lib2();
~Lib2();
void run() const;
};
B/src/lib2.cc
#include <iostream>
#include <lib1.hh>
#include <lib2.hh>
class Lib2::Implementation {
const Lib1 m_lib1{};
public:
void run() const { std::cout << "using lib1 from lib2: "; m_lib1.run(); }
};
Lib2::Lib2() : impl{new Implementation} {}
Lib2::~Lib2() { delete impl; };
void Lib2::run() const { impl->run(); }
App/src/app.cc
#include <lib2.hh>
int main() { Lib2 l; l.run(); }
App/CMakeLists.cc
cmake_minimum_required(VERSION 3.14)
project(App)
include_directories(include "${LIB2_ROOT}/include")
find_library(LIB2 lib2 "${LIB2_ROOT}/lib")
add_executable(app src/main.cc)
target_link_libraries(app "${LIB2}")
install(TARGETS app DESTINATION "${CMAKE_CURRENT_SOURCE_DIR}/bin")
我对B使用了PIMPL模式，因为当我让我的库的用户无论如何都要挖出所有标头时，隐藏链接依赖关系有什么意义。
最后B/CMakeLists.txt(对于我的库)取决于我上面提到的情况：
A&A和B静态
B/CMakeLists.txt
cmake_minimum_required(VERSION 3.14)
project(B)
include_directories(include "${LIB1_ROOT}/include")
find_library(LIB1 lib1 "${LIB1_ROOT}/lib")
add_library(lib2_dependent src/lib2.cc)
add_custom_target(lib2 ALL
COMMAND ar -x "${LIB1}"
COMMAND ar -x "$<TARGET_FILE:lib2_dependent>"
COMMAND ar -qcs "${CMAKE_STATIC_LIBRARY_PREFIX}lib2${CMAKE_STATIC_LIBRARY_SUFFIX}" *.o
COMMAND rm *.o
DEPENDS lib2_dependent
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/lib"
)
此解决方案来自我在开始时链接的问题。在我看来，this answerUsing
中还有一个更好的版本ar -M <<EOM
CREATE lib2.a
ADDLIB lib1.a
ADDLIB lib2_dependent.a
SAVE
END
EOM
A静态，B共享
就我在这种情况下所发现的，如果我不能重新组合A，并且它不被编译为位置无关的代码，那么我就不走运了。第二个最好的办法就是将set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")添加到A/CMakeLists.txt。同样，似乎还有更好的替代方案：set(CMAKE_POSITION_INDEPENDENT_CODE ON)或set_property(TARGET lib1 PROPERTY POSITION_INDEPENDENT_CODE ON)中的here，在我的例子中完全被忽略。(使用VERBOSE=1编译，任何地方都看不到-fPIC标志，B没有编译)
在这种情况下，B/CMakeLists.txt很容易
cmake_minimum_required(VERSION 3.14)
project(B)
include_directories(include "${LIB1_ROOT}/include")
find_library(LIB1 lib1 "${LIB1_ROOT}/lib")
add_library(lib2 SHARED src/lib2.cc)
target_link_libraries(lib2 "${LIB1}")
install(TARGETS lib2 DESTINATION "${CMAKE_CURRENT_SOURCE_DIR}/lib")
虽然我没有发现这个解决方案有任何问题，但根据答案，我发现我应该需要设置额外的标志，比如set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--export-all-symbols")，这样才能找到静态库中的符号。但是，上面的程序运行正常，编译正常，App运行没有问题？+q+我在这里做错了什么吗？，或者可能是由于这些旧的答案对CMake进行了某些更新？
A共享、B静态或两者都共享
根据我在这里发现的，这基本上是不可能的，因为共享库在某种意义上是最终的。我觉得这很奇怪，肯定有很多库不需要使用它们来链接恰好是共享库的库的每个依赖项的项目？+q+在这些情况下真的没有选择吗？推荐答案
是的，您做错了：)
CMake方法是使用packages。一旦您创建了LibA包，您只需在B/CMakeLists.txt中执行find_package(LibA)，并且生成的LibBConfig.cmake(包配置文件，因此您的客户端只需要在其App/CMakeLists.txt中使用find_package(libB))应该以相同的方式(使用或不使用CMake的帮助器find_dependency)查找(这是有问题的IMHO，但目前是它的CMake方式)。
这样整个过程就简单多了：
- 您完全控制如何构建(包括版本、库类型静态/动态等)以及在开发人员的主机和客户的计算机上安装
libA的位置(以便从属项目可以找到它) libB和App相同- 您和您的库的任何客户使用众所周知的CMake方法查找依赖项并完全控制此过程
- 最重要的让CMake代替您做复杂的事情，这使您的构建逻辑在所有涉及的项目中
CMakeLists.txt更简单
这篇关于隐藏可传递的外部依赖项/将库与CMake相结合(&H)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！