电子艺术和visualstudio的Linux支持

Electronic Arts（EA）使用visualstudio的跨平台支持在Windows上进行交叉编译，在Linux上进行调试。下面的帖子是由EA工程工作流高级软件工程师Ben May撰写的。感谢本和EA的合作伙伴关系，并帮助我们使VisualStudio成为C++跨平台开发的最佳IDE。

在EA，我们的Frosteite引擎有一个Linux组件，用于我们的专用服务器，为许多最流行的游戏提供服务。  当我们看到微软在visualstudio的工作负载中增加了对Linux的支持时，这引起了我的兴趣！  在EA，我们的游戏开发人员习惯于Windows环境下进行开发，因此我们认为强迫他们直接在Linux环境下进行开发将是一个困难的任务，因此我们决定使用clang和交叉编译从Windows和target Linux进行开发。  最初，我们自己用visualstudio Makefile项目来构建源代码，然后使用各种工具通过ssh将二进制文件复制到Linux机器上，然后编写工具在远程Linux机器上启动gdbserver，以便能够从PC进行调试。  在visualstudiolinux工作负载发布之后，我们发现微软基本上把所有的工具/进程都很好地打包到了一个visualstudio工作负载中，我们可以要求开发人员直接在visualstudio中安装和调试！  到目前为止，与WSL和工作负载提供的远程调试的集成已经取得了成功，并彻底清理了我们围绕Linux调试/开发的工具/进程。  我们的开发人员对改进后的体验非常满意。

我现在将更详细地解释我们实际上在做什么。

内部生成设置

我们的内部构建设置使用我们自己的专有工具，采用我们自己的跨平台构建格式，并在我们决定将Linux添加到支持的平台列表时生成多种类型的输出（vcxproj/csproj/make等），我们决定，我们将为我们的开发人员设置我们的主要工作流程，以便从基于Windows的PC和visualstudio启动，因为这是我们用于几乎所有其他平台的环境。  另一个要求是我们的CI（持续集成/构建场）能够验证我们在Linux上编译的代码，而不需要设置基于Linux主机的CI vm，也不需要远程Linux系统来编译代码，因为管理和支持这将更加昂贵和复杂。  这些要求基本上导致我们决定直接在PC上使用clang在Windows上交叉编译我们的代码库。

对于我们的交叉编译器，我们使用一种叫做“加拿大交叉”的编译器设置。  看到了吗 工具链类型 有关交叉编译类型的更多详细信息，请参见维基百科的“加拿大交叉”链接。  它是“加拿大十字”的主要原因是，我们在Linux机器上构建了LLVM和GCC工具链，并将它们的部分转移到Windows机器上与Windows clang结合使用。  基于此，我们在Windows上的交叉编译器设置包含以下内容：

1. 我们使用 LLVM公司
2. 我们将LLVM的Windows版本与Windows机器上的Linux版本相结合。  这是为了获得针对Linux所需的所有libs/头。
3. 我们还将GCC工具链与LLVM一起使用。  为了构建适用于Windows的gcc工具，我们使用 交叉工具NG 在Linux主机上构建它。
4. 然后在构建时需要传递-target x86u 64-pc-linux-gnu和-sysroot=
5. 您可能需要首先使用-Wno nonportable include path warning suppression，因为Windows不区分大小写，并且修复所有include path错误可能有点冗长（尽管我建议这样做！）

在我们组装好工具链之后，我们使用我们的专用生成器生成Makefile，这些Makefile为我们构建代码，但是引用了上面的交叉编译器设置，然后是一组vcxproj文件，它们的类型是“Linux Makefile”和.sln文件。  此时，我们进入visualstudio，使用visualstudiolinux工作负载将工作流集成到IDE中。

Visual Studio集成

开发人员需要确保他们拥有 用C++开发Linux ’ 安装的工作量：

在确保安装了正确的组件之后，我们使用Linux Makefile项目的内置特性来工作。  为了构建代码，我们只需在visualstudio中选择build，这将执行交叉编译器并输出二进制文件。  visualstudiolinux项目内置了在Linux主机上部署和调试的功能。

在WSL上调试

我们可以将生成器配置为使用两种不同的部署/调试设置：

1. WSL公司( Linux的Windows子系统 )
2. 远程Linux主机

最方便的设置是WSL，假设您不必在屏幕上呈现任何内容。  换句话说，如果您只需要开发无头单元测试或控制台应用程序，那么这是最简单、最快的迭代方式。

如果开发人员正在使用WSL，那么实际上不需要部署二进制文件，因为WSL可以直接从当前的Windows机器访问二进制文件，这节省了时间，因为它们不再需要复制/部署到远程机器上（我们的一些二进制文件可能会变得相当大，因此有时可以为增量构建+调试会话添加几秒钟）

这是我建造的一个例子 伊斯特 ，一个开源的EAs库， 使用Visual Studio Linux Makefile项目和我们的交叉编译器：

您可以看到我在那里放置了一个断点，并且我将我的环境配置为在运行时使用WSL，因此当我调试时，它将在WSL中启动测试二进制文件，并使用visualstudio的gdb调试器连接调试器，而不需要首先复制二进制文件。  通过设置 远程生成根目录、项目目录和部署目录 路径是指向Windows计算机上同一文件夹的WSL路径。

下面是我调试并命中断点，然后继续运行并完成单元测试的一个快速示例：

在远程Linux系统上调试

对于不使用WSL的远程Linux机器设置，唯一需要担心的是构建的可执行文件及其依赖的动态库或内容文件的部署。  我们这样做的方法是设置一个源文件到远程映射，并让visualstudio的post-build事件复制该文件。  “下的exe项目的属性内部” “生成事件”->“生成后事件”->“要复制的其他文件” ” ，我们指定生成完成后需要复制到远程计算机的文件列表。  这是必须的，这样当我们单击“调试”时，二进制文件就已经在远程机器上了。

您可以看到，语法是本地路径到远程路径的映射，这对于在两个文件系统之间映射文件非常方便。

对未来的要求

这样做的一个缺点是部署是在“构建”阶段完成的，我们理想的做法是在使用Linux时有3个不同的阶段：

1. 建造
2. 部署
3. 调试

这样您就可以在不需要连接到远程机器的情况下构建代码，这在CI环境中非常有用，或者在有些人只想在本地构建和修复Linux的编译问题并提交这些问题并让自动测试验证其修复的环境中非常有用。  拥有不同的部署和调试阶段也很好，这样您就可以从visualstudio进行部署，但可能会直接从Linux机器调用/Debug等。

此时还值得注意的是，我们仍然使用make“under the hood”来执行针对Linux的构建，但是visualstudiolinux工作负载还支持一个完整的基于MSBuild的Linux项目。  目前我们还没有花太多时间来尝试这一点，但是如果我们能够使用这一点，就像我们为大多数其他平台所做的那样，努力使用MSBuild来构建Linux，那就太好了。

我们一直在与Visual Studio团队密切合作开发Linux组件，并密切关注Visual Studio 2019预览版的构建，以测试和迭代这些工作流，我们希望在未来的版本中能够：

1. 完全分离本地交叉编译场景的构建、部署和调试 .
2. “设置” Linux Makefile项目中的增量“构建+部署”检测 因此，我们不需要为解决方案中的所有项目重新启动make（我们的一些大型解决方案有超过500个项目）。  这主要是为了更快地增加迭代时间。
3. 我们已经要求 直接WSL调试 添加到Linux Makefile项目中，目前在我们的设置中，因为Linux Makefile项目不直接支持WSL，所以我们仍然需要通过ssh连接调试WSL，这意味着我们必须在WSL上运行sshd。这种支持已经与基于MSBuild的Linux应用程序和CMake项目集成，但还没有集成到Makefile项目中。
4. 尝试使用基于MSBuild的Linux项目文件，并与Microsoft合作，使这些文件可以使用本地工具链（我们的交叉编译器）进行操作，但仍然可以为部署和调试提供相同的功能。  这也将帮助我们解决上面提到的Makefile增量问题。

总而言之，这个工作流程对我们来说非常流畅！  它允许我们的开发人员使用IDE和操作系统，他们在舒适的工作，但仍然能够建立和调试Linux应用程序！

-Ben May，EA工程工作流高级软件工程师

再次感谢你的合作，本！我们的团队期待着根据社区的反馈继续改进产品。如果您对在Windows和Linux上构建相同的项目感兴趣，请查看我们对CMake的本机支持。你可以看一个类似的故事写的 Oracle的MySQL服务器团队 .