C++ 为什么bcp会为Boost program_选项计算如此大的依赖项列表？

我正在编写一个小程序，使用

boost/program\u options

处理命令行中的选项。现在，我想将代码分发到通常未安装Boost的系统。因此，我使用了

bcp

实用程序。我在Boost中名为

example/first.cpp的示例上试用了它，该示例来自：

它创建了一个目录
dest
，其中包含大量
.hpp
和
.cpp
文件。我想这就是我需要的，不再需要了。这是对的吗？因为：

du -hs dest
37M dest

3700万不是太多了吗？例如，我可以使用Python和
test\u optpasse.py
做同样的事情，只需61KB

我做错什么了吗？关键是我的源程序只有4MB；我无法添加37MB的第三方内容
 关于这个话题，我无法提供更多的解释。最值得注意的是：

应当指出，在实践中
bcp可以生成一个相当“丰富”的
依赖关系，原因是什么
包括：

[……]


当您包含头时，
bcp
不知道您是什么编译器
使用，所以它遵循所有可能的
预处理器路径。如果你是
使用
你在申请那是什么
您希望在一般情况下发生。

与大多数人的期望相比，上面最后一点可能会导致发现的标题数量大幅增加例如，bcp为boost/shared查找274个标头依赖项。hpp:通过在报告模式下运行bcp，我们可以了解为什么所有这些标头都被查找为依赖项

我建议您尝试
bcp--report
，并检查包含每个文件的原因，看看是否确实有必要。
是否要分发您的代码或可执行文件？@icecrime:我想分发代码以及使用g++3/4在linux上编译所需的所有文件。您为什么不希望boost作为依赖项？运行时库包含在大多数发行版中，而devel软件包可从大多数软件包管理器获得。我的合作者很懒惰，通常我们运行的系统对您可以安装什么有严格的规则。您的目标是什么发行版？好的，这将生成一个HTML，最后是依赖项列表。但这对我帮助不大。我可以删除如下文件：
boost/config/compiler/borland.hpp
。有没有一种自动的方法只保留必要的信息？顺便说一句，要点更一般：为什么我需要
any.hpp
，
lexical\u cast
，
mpl
等等，只是为了从命令行解析选项？我不明白。我认为我可以只使用
和
@wiso编写一个非常基本的选项解析器：不幸的是，我认为这种“清理”必须是手动的。。。关于依赖关系，我对boost.program\u options实现的了解还不够，无法给您提供解释，但我假设如果
bcp
仅为shared\u ptr.hpp生成274个头，那么一切都是可能的。@Wiso，如果您只想从命令行解析选项，那么请自己阅读
argv
和
argc
。但是，如果您想要Boost所能做的所有整洁的事情，比如有一个用于指定程序选项的简明语法，自动生成帮助消息，并以类型安全的方式存储选项的值，那么您确实需要
any
，
lexical\u cast
，和
mpl
，以及它们的所有依赖项。@Wiso，请注意，文档中有一些关于为单个环境获取一组包含的建议：“如果您想知道特定编译器正在使用哪些Boost标头，那么最好的方法是预处理代码并扫描Boost标头包含的输出。”也就是说，运行类似于
g++-E~/prova/first.cpp | grep'#include.*boost'
。（你可以使用一个更奇特的grep模式，或者尝试以某种方式过滤输出，但这应该可以让你开始了。）注意bcp文档最后一句中的警告。
du -hs dest
37M dest