问题描述

我不想在交叉编译项目的源代码树中包含静态库，我想直接将 boost 添加到 cmake 中并构建它.这个可以用吗?

Rather than include static libraries in my source tree in a cross-compiled project I'd like to add boost directly into cmake and build it. Is this available?

推荐答案

我们在我的工作场所也遇到了这个问题.虽然我当然不能声称知道最好"的方式，但我可以根据我的经验提供以下想法.

We've struggled with this a fair bit too at my workplace. While I certainly can't claim to know the "best" way, I can offer the following thoughts on my experiences.

我们最初只要求开发人员单独安装 boost，并让 CMake 以 find_package(Boost...) 调用.这很容易，但不是自动化的，并且会给已经安装了旧版 boost 的开发人员带来问题.

We initially just required devs to install boost separately and had CMake do its normal checks in the form of a find_package(Boost...) call. This was easy, but not automated, and caused problems for devs with older versions of boost already installed.

然后我们改变了策略并添加了我们从您上面提到的项目之一克隆的 boost 源的副本.我不记得具体细节，但我认为这是 Ryppl 项目中目前正在开展的工作的前身.重点是它已经支持 CMake；boost 库是通过 add_library 调用添加的实际 CMake 目标，这使得它们更容易在 CMake 代码中使用.

We then changed tack and added a copy of the boost sources which we cloned from one of the projects you mentioned above. I can't recall the specifics, but I think it was a precursor to the one currently being worked on in the Ryppl project. The main point was that it already had support for CMake; the boost libraries were actual CMake targets added via add_library calls, which made them easier to work with in the CMake code.

虽然通过在我们的项目中自动化使用 boost 解决了之前的问题，但它最终变成了维护的噩梦.我们克隆的 boost 项目发生了根本性的变化，现在非常依赖于 Ryppl 特定的 CMake 函数.我们不想添加 Ryppl 作为依赖项，所以我们再次改变了策略！

While this solved the previous problems by automating the use of boost in our project, it ultimately became a maintenance nightmare. The boost project we had cloned from changed radically and is now very dependent on Ryppl-specific CMake functions. We didn't want to add Ryppl as a dependency, so we changed tack again!

我们查看了您在问题中提到的项目，同样没有发现它们可用.

We looked at the projects you mentioned in your question, and likewise found none of them to be usable.

我们当前的设置使用了 CMake 的 ExternalProject 模块.这允许我们下载并构建我们的构建树.

Our current setup makes use of CMake's ExternalProject module. This allows us to download and build boost to our build tree.

优点:

• 低维护
• 自动化，因此所有开发人员都使用使用相同标志构建的相同版本
• 让我们自己的源代码树不受第三方代码的影响
• 多个 boost 副本可以愉快地共存(因此不会意外链接到使用不同编译器/stdlib 组合构建的副本)

缺点

• 删除构建树意味着必须从头开始下载和构建 boost.这可以通过例如改善下载到固定位置(例如系统临时目录)，因此如果找到现有的 boost 源副本，则可以跳过下载/解压缩步骤.
• boost 库不是正确的 CMake 目标(即它们没有通过 add_library 调用添加)

• Deleting your build tree means having to download and build boost from scratch. This could be ameliorated by e.g. downloading to a fixed location (say, system temp dir), so the download/unzip step could be skipped if an existing copy of the boost sources is found.
• The boost libraries are not proper CMake targets (i.e. they haven't been added via add_library calls)

这是我们的 CMake 代码的链接.有几种方法可以改善这种情况，但目前对我们来说效果还不错.

Here's a link to our CMake code. There are a few ways in which this needs improved, but it currently works reasonably well for us.

我希望这个答案很快就会过时，并且可以使用像样的、模块化的、与 CMake 兼容的解决方案.

I hope that soon this answer becomes out of date and a decent, modularised, CMake-compatible solution becomes available.

这篇关于是否可以使用 CMake 构建 Boost?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！