问题摘要
我们使用 cotire （Compile-Time Reducer）作为我们的预编译头系统，因为使用Boost C ++模板库导致了极长的编译时间。我们变得很糟糕，结果很危险 - 预编译的标题似乎不断重建，偶尔会掩盖构建问题。具体来说，背靠背构建会导致实际cotire预编译头文件本身的哈希值不同，并且在尝试增量构建时，每次都会重建预编译头文件，即使没有头文件材料发生更改。
背景
该项目是一个使用g ++ 6.3.1的Linux CMake构建，它作为工件产生一个可安装的共享库和几个可执行文件。可能值得注意的是，由于对快速迭代开发的不断要求，我们对使用单一构建没有兴趣。然而，该项目非常庞大，因此对cotire感兴趣。
值得注意的是，为了避免在解决此问题时出现意外交互，我们已禁用 ccache ，即编译器缓存。 （我们的目的是最终启用ccache，当且仅当我们从cotire获得一致的预期结果，或者在我们放弃并删除cotire之后。）
该项目使用C ++ 03（虽然构建11并没有为了这个问题而改变我们的结果）并且广泛依赖于Boost C ++库。具体来说，我们不断使用Boost Signal-Slot，boost :: bind，boost :: function以及相当多的迭代功能。 Boost通过广泛的模板元编程和变体自包含来实现所有这些。
黑名单＆＃34;有可能，但并非完全直截了当。来自cotire的头文件，从生成的预编译头中排除它们。我们试图将Boost内部的各个子目录列入黑名单（Boost包含大约900个不同的头文件，因此我们主要将自己局限于其直接的子目录）。这似乎产生了改进的结果 - 将Boost的某些部分列入黑名单导致背对背的干净构建，从而产生匹配的预编译头部哈希值。
不幸的是，经过一次更大的延迟 - 可能是十分钟 - 第三次尝试进行干净的构建会导致预编译头的哈希值不同。
此时，我们的工作理论是各种特殊的预处理器符号，例如__TIME__和__DATE__，以某种方式被误导到cotire的输入中。在Boost的标题中搜索这些内容确实会在wave，spirit等中产生一些命中。据推测这会导致cotire相信标题已经以某种方式发生了变化，因为它试图重建整个预编译的标题。构建（虽然不是每个编译单元;我们暂时相信我们已将它正确地集成到构建过程中）。
问题
有没有人成功地使用gcc / g ++和Boost的cotire？是否需要任何不寻常的步骤，而不是在没有Boost的项目中使用cotire？
我们对cotire 特别感兴趣;例如，Visual Studio的预编译头系统的结果可能很有趣但不太可能有用。但是，如果您要解决类似问题并希望在此处提供您的观察，请随时这样做。