“隐藏”可传递的外部依赖关系/将库与CMake结合使用

如何解决“隐藏”可传递的外部依赖关系/将库与CMake结合使用

这个问题可能是部分重复的，例如this question，但更多内容是更好的解决方案。由于这个问题用了很长的时间，所以我在 特定问题 上加了“ + Q + ”。 / p>

我遇到的情况是，我编写了一个小型库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\n"; }

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和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 answer中还有一个更好的版本，使用

ar -M <<EOM
    CREATE lib2.a
    ADDLIB lib1.a
    ADDLIB lib2_dependent.a
    SAVE
    END
EOM

但是我无法使用CMakeLists.txt中的here-document ...？还有一个额外的答案提供了我认为是实现此功能的CMake函数，但这是一大段代码，我发现对于应该简单/标准实践/集成到其中的某些内容有些荒谬CMake的？ 我在这里编写的custom_target解决方案也可以使用，但是也正如其他答案中所提到的，对于我想以此方式编译的每个库，它都解压缩了位于周围的对象文件，必须再次将其删除。 仍然在这两种情况下，我仅想知道使用CMake有什么意义，那么无论如何我都必须手动使用ar。 + Q +有没有更好的/ CMake集成方式来“编译”传递依赖项/组合静态库？

---

A静态，B共享

就我在这种情况下发现的而言，如果我不能重新填写A且没有将其编译为与位置无关的代码，我很不走运。使它起作用的下一个最佳方法就是通过在{strong> A / CMakeLists.txt 中添加set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")来实现。同样，似乎还有更好的选择：here中的set(CMAKE_POSITION_INDEPENDENT_CODE ON)或set_property(TARGET lib1 PROPERTY POSITION_INDEPENDENT_CODE ON)，在我的情况下它们被完全忽略了..（使用VERBOSE=1进行编译，没有{{ 1}}标志可以在任何地方看到，而-fPIC未编译）

在这种情况下， B / CMakeLists.txt 很简单

B

虽然我发现此解决方案没有任何问题，但根据回答，我发现我应该需要设置其他标志，例如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")可以正常运行吗？ + Q +我在这里做错什么了吗？还是可能是由于这些较旧的答案以来对CMake的更新？

---

A共享，B静态或两者共享

根据我在这里找到的内容，这基本上是不可能的，因为共享库在某种意义上是“最终的”。我发现这很奇怪，肯定有很多库不需要使用它们来链接恰好是共享库的库的每个依赖项的项目吗？ + Q +在这些情况下真的没有选择吗？

解决方法

是的，您做错了：）

CMake方式将使用packages。制作完LibA软件包后，您只需在find_package(LibA)和生成的B/CMakeLists.txt（软件包配置文件）中进行LibBConfig.cmake，因此您的客户只需要{ {1}}在其find_package(libB)中应该以相同的方式（无论是否使用CMake的助手find_dependency）找到（这是可疑的恕我直言，但目前是其CMake方式）。

整个过程变得更加简单：

• 您已经/完全控制了如何构建（包括哪个版本，库类型为静态/动态等）以及在开发人员的主机和客户的计算机上安装App/CMakeLists.txt的位置（因此相关项目可以找到它）
• 与libA和libB相同
• 您和您的图书馆的任何客户都使用众所周知的CMake方法来查找依赖项并完全控制此过程
• 和最重要的让CMake代替您完成复杂的事情，这使您所有相关项目的App中的构建逻辑都更加简单