vcpkg新特性：交叉编译下的主机依赖关系

如果你还不熟悉我们的C++包管理器vcpkg，那么：欢迎阅读本文。
今天的这篇文章，我们将覆盖一些关于vcpkg的中高级主题，所以，你可能需要先从我们之前的博文中了解一下vcpkg的概念性知识，最好能亲自动手做一些小实验，以加深理解。

介绍
C ++的最佳功能之一是，它为每台特定的机器生成量身定制的专用代码，使你能够最大程度地榨取机器的每一分性能，它使干净的抽象与特定于底层平台的细节平稳地共存。
但是，很多开发人员也会为这一收益付出一定的代价：与最终目标平台相比，你必须为开发人员计算机构建不同的二进制文件，目标平台可能是一个移动手机平台，一台云服务器，甚至是一个嵌入式系统。

对于小型或中型工程来说，这可能并不是一个很大的问题。
你已经拥有一个编译器，一个代码编辑器和一个构建系统，这足以用来开发大量令人难以置信的应用程序。但是，由于时间久远，一些开发人员不仅需要编译器，还需要更多的灵活性，可扩展性和强大功能；他们需要在构建时生成复杂的代码。
可能是在基于一个已知数据集合的哈希值计算程序，也可能是嵌入式脚本语言中的一堆外部功能接口模板。不管原因是什么，除了最终的运行时目标之外，你还需要C++在开发环境中的灵活性。

下面，我们会介绍解决上述问题的vcpkg的新功能：Host Dependencies(主机依赖)。

并行编译
如引言中所述，由于C++会一直持续进行编译，因此你通常无法使用相同的编译器和标志同时用于目标平台和开发平台。如果你使用的是多目标平台编译器（例如Clang / LLVM），则至少需要使用不同的编译标志；如果你使用的是单目标编译器（例如GCC或MSVC），则需要使用完全不同的编译器。

如果幸运的话，构建系统会提供有关如何处理这种情况的文档。即使那样，为了确保各个配置都正确得到配置，编译过程也会变得非常复杂：你是否意外地将目标平台的编译标志传递给开发平台版本? 如果你需要运行代码生成器的库该怎么办? 如果代码生成器为其他代码生成器生成代码又如何处理呢？这是一个棘手的问题集合，会对构建环境的各个方面都产生影响。

Triplets
在vcpkg中，我们将每个目标平台空间标记为单独的“triplet”。
举个例子，使用动态CRT和MSVC的x64 Windows桌面系统，在构建静态库时的名称可能为x64-windows-static-md。在该空间中构建的每个库都与该空间中的其他库链接，从而使所有内容保持超级一致。
我们在框架中包含许多预定义的triplet，但是你可以轻松地自己调整每个库的编译器标志或调整设置(例如，你希望动态构建Qt，但是JSON解析器是静态构建的)。

自然，你的开发环境也匹配这些空间中的某一个。 默认情况下，我们选择适当的x64-windows，x64-linux或x64-osx，但可以在运行时通过多种方法对其进行完全配置。

主机依赖
尽管vcpkg具有与开发人员环境匹配的triplet，但是vcpkg的合适的语法表示对环境构建库的依赖性。 我们已经采用了一些不那么完善的方法，例如动态地尝试从一组硬编码的后备triplet中使用库，但是，这些方法始终不是最好的。
这些变通办法在清单模式下也不能正常工作，这是专门设计用来防止在此类“动态”访问中发生的意外行为。 当然，这个修正方法是一种自然而直接地表达对为开发人员环境构建库要求的方法。

现在可以正式引入主机依赖的特性了。
它的语法非常简单，就是在依赖项的清单文件中设置host为true，如下图所示：

在执行期间，库可以知道，它的所有依赖库都已安装到CURRENT_HOST_INSTALLED_DIR指定的位置，并且它们可以通过HOST_TRIPLET（TARGET_TRIPLET的模拟）获取当前配置的主机triplet。

对于内部嵌入了自己的代码生成器的项目，要求自己为主机构建是完全有效的：

然后，库可以通过比较triplets来确定它是交叉编译还是本地编译：

总结
我们才刚刚开始将这种功能强大的新功能合并到现有功能中，例如Boost.Build。 对于面向新兴开发平台（例如iOS，安卓和Emscripten/WebAssembly）的vcpkg用户而言，这是巨大的进步。

最后
Microsoft Visual C++团队的博客是我非常喜欢的博客之一，里面有很多关于Visual C++的知识和最新开发进展。大浪淘沙，如果你对Visual C++这门古老的技术还是那么感兴趣，则可以经常去他们那(或者我这)逛逛。
本文来自：《vcpkg Host Dependencies for Cross-Compilation》