发送源代码时省略未使用的 boost src 文件的策略

Posted

技术标签:

【中文标题】发送源代码时省略未使用的 boost src 文件的策略【英文标题】:Strategy to omit unused boost src files while shipping source code 【发布时间】:2018-07-14 10:07:51 【问题描述】:

我正在使用

#include <boost/numeric/ublas/matrix.hpp>

事实上,这是我包含的唯一 boost 文件。现在我想发布源代码,我希望不必包含所有数百 MB 的 boost_1_67_0

如何处理这个问题?

【问题讨论】:

头文件可能需要它们包含的其他头文件。不能保证仅标头库的头文件都是自包含的。 仅发布您的源代码,并充分证明对 Boost ublas 的依赖。然后,如果您的源代码的用户想要构建它,则需要自己安装 Boost。这是在开源世界中处理公共库依赖项的常用方法。 如果我发布了使用boost的源代码,我只是将boost列为开发环境的前提条件,并留给消费者自己获取最新boost版本的副本。 【参考方案1】:

这只是您将添加到 C++ 源代码的构建依赖项列表中的内容。

这种依赖可以通过您的版本控制系统在技术上“绑定”到您的源代码分发。例如,在Git 中,您可以通过链接到其官方 git 镜像的子模块链接到某些 Boost 库(撰写本文时为github.com/boostorg)。在克隆您的存储库时,可以选择同时获取 Boost 库。

不过,考虑到 Boost 标头的大小,将它们安装为系统范围的库,可能不会那么复杂。 CMake 之类的工具可以帮助您编写包含标头的逻辑,以便您可以支持不同的标头位置。

当然,如果您想要创建一个完全隔离的源代码副本,那么将所有代码烘焙到一个庞大的头文件中的方法也可能是一种选择(但应该不是必需的)。

【讨论】:

我可以再问一些关于 CMake 方法的内容吗?我应该在哪里寻找什么? @KcFnMi CMake 是一个拥有自己的脚本语言(CMake language)的工具。它被用作“元编译器”;一个可以为您的编译器工具链生成必要的 makefile 的工具。这使得支持多种工具链成为可能,无论是 GCC、Clang 还是 Microsoft Visual Studio。如果您不熟悉 CMake,则需要花费一些时间和精力来学习它(它是另一种语言)。幸运的是,它的文档写得很好,所需的一切都是时间和理由。【参考方案2】:

您可以预处理您需要的一个头文件,这将扩展其所有#includes:

c++ -E /usr/include/boost/numeric/ublas/matrix.hpp -o boost_numeric_ublas_matrix.hpp

但请注意:这甚至会扩展您的系统头文件,因此它假定您的用户将在同一平台上构建。如果他们可能在不同的平台上编译,你应该简单地从你的项目中省略 Boost 代码,让用户以他们选择的任何方式自己安装它。

【讨论】:

以上是关于发送源代码时省略未使用的 boost src 文件的策略的主要内容,如果未能解决你的问题,请参考以下文章

boost async_write:如果失败,如何跟踪未发送的内容并通知客户端/用户失败的内容?

对 boost asio 的未定义引用

链接到 MacOS 上预编译的 QuantLib 二进制文件时未定义的 Boost 符号

Boost Log 清除日志文件

boost:asio::async_write:数据已发送但未调用处理程序

boost::async_write 导致数据损坏