waf编译框架_编译器测试框架

waf编译框架

Unity, as you may know, helps you build for many different platforms, be it consoles, computers, mobiles or XR. In order to do this, it uses things like a compiler, specific compiler flags, various SDKs, third party libraries and maybe even a specific OS required by the platforms. We call this combination of software strung together a Toolchain.

您可能知道，Unity可以帮助您针对许多不同的平台进行构建，无论是控制台，计算机，移动设备还是XR。 为了做到这一点，它使用诸如编译器，特定的编译器标志，各种SDK，第三方库，甚至平台所需的特定OS之类的东西。 我们称这种串在一起的软件为工具链。

So as consoles, VR headsets, phone or smart tv OS are introduced or made obsolete, or just updated, we need to tinker with these Toolchains and/or make necessary code changes to the Unity codebase to keep everything working as intended.

因此，随着控制台，VR头戴式耳机，电话或智能电视OS的引入，过时或刚刚更新，我们需要修改这些工具链和/或对Unity代码库进行必要的代码更改，以使所有功能按预期运行。

我们要解决什么？ (What Are We Trying to Solve?)

As with all software there is, more often than you’d think, unexpected behaviour. This could be everything from bugs to undocumented behaviour. Compilers and SDKs aren’t immune to things such as these either, and like any other software they’re also affected by software updates. You may have undocumented behaviour you’re relying on change suddenly or bugs being fixed and/or introduced as you perform an update. Add to this that different platforms may support wildly different feature sets, with some being bleeding edge and others more archaic.

与所有软件一样，出乎意料的是，往往比您想象的要多。 从错误到未记录的行为，这无所不包。 编译器和SDK也不是不会受到诸如此类的影响，并且像其他任何软件一样，它们也受到软件更新的影响。 您可能会出现一些未记录的行为，您可能会突然依赖于更改，或者在执行更新时已修复和/或引入了错误。 除此之外，不同的平台可能支持截然不同的功能集，其中一些功能非常先进，而另一些则更古老。

Having some order in this and keeping track of changes seems like a good thing.

在其中进行一些排序并跟踪更改似乎是一件好事。

Over the years there are many scenarios we handle for our Toolchains, such as bugs in specific compilers or certain toolchains lacking some compiler features. Even the now somewhat old C++11 isn’t something we can use across our entire code base, since simply some of our platforms do not, and can’t support it.

多年来，我们为工具链处理的场景很多，例如特定编译器中的错误或缺少某些编译器功能的某些工具链。 即使是现在已经有些陈旧的C ++ 11，我们也无法在整个代码库中使用，因为仅我们的某些平台不支持也不支持。

Based on the state of these different toolchains at one point in time, we need to take different strategies.

根据某一时刻这些不同工具链的状态，我们需要采取不同的策略。

This means it would be possible for these fixes to work around a problem, to long outlive the issues themselves and remain left in the code, warning future people of a problem that really isn’t a problem anymore.

这意味着这些修补程序有可能解决问题，使问题本身长期存在并保留在代码中，从而警告未来的人们确实不再是问题的问题。

So we need to stay on top of what is fixed, broken, supported and unsupported for our Toolchains as they get added, updated or left by the wayside.

因此，当我们的工具链被添加，更新或遗留在路边时，我们需要紧跟其固定，损坏，受支持和不受支持的内容。

Another issue is the round-trip time for our developers who are working at the lower levels of our code base. Today if they’re, for example, making some new macros and want to be sure it will work across all our Toolchains, they end up having to build the editor on our build system for each platform just to find out if it will compile. That is a very time consuming and a lot of wasted resources for our build farm just to see if a macro will compile or not.

另一个问题是在较低代码层工作的开发人员的往返时间。 今天，例如，如果他们要制作一些新的宏，并想确保它可以在我们所有的工具链中使用，那么他们最终不得不在我们的构建系统上为每个平台构建编辑器，只是想知道它是否可以编译。 仅仅查看宏是否将编译，这对于我们的构建场来说是非常耗时的，并且浪费了大量资源。

So this is also something we want to try to improve.

因此，这也是我们要尝试改进的方面。

什么是编译器测试框架？ (What is The Compiler Test Framework?)

It’s a series of C# NUnit tests written as small C or C++ snippets that get compiled against all our Toolchains. Each test contains one code snippet which asserts on the  behaviour we’re expecting. Even if this behaviour is in fact a bug and doesn’t compile, this is still a behaviour we expect and will write a test for it. So if down the line it’s fixed for a compiler or an SDK update, we will be notified, and maybe that will mean we can finally use that compiler feature across all our platforms.

这是一系列用小型C或C ++代码段编写的C＃NUnit测试，并针对我们所有的工具链进行了编译。 每个测试包含一个代码段，这些代码段声明了我们期望的行为。 即使此行为实际上是一个错误且无法编译，也仍然是我们期望的行为，并将为此编写测试。 因此，如果将其固定用于编译器或SDK更新，我们将收到通知，也许这意味着我们最终可以在所有平台上使用该编译器功能。

The framework for now only compiles the snippets, so it won’t actually run the binary it generates or in any way analyses it. So there can be no runtime assertions done in the tests, only static ones.

现在，该框架仅编译代码片段，因此它实际上不会运行它生成的二进制文件或以任何方式对其进行分析。 因此，测试中不能有任何运行时断言，只有静态断言。

The compiler tests utilize our build system, which is made in C#, for all the heavy lifting, and lets it run the build for our Toolchains and uses the snippet in the test as the source files for it.

编译器测试使用了C＃中的构建系统来完成所有繁重的工作，并使其运行我们的工具链的构建，并将测试中的代码片段用作其源文件。

Doing this lets us assert on compiler output, including build errors and warnings. So we can do things like saying “This code works for all our Toolchains except for these two, and for these two it will print this error message” and mark the test as successful as long as this remains true.

这样做使我们可以断言编译器的输出，包括构建错误和警告。 因此，我们可以做一些事情，例如说“此代码对我们的所有工具链都适用，除了这两个之外，对于这两个，它将打印此错误消息”，并在测试保持成功的情况下将测试标记为成功。

You may think it’s weird that a build failure should still let a test succeed, but the compiler tests are all about writing down our assumptions about the toolchains.

您可能会认为构建失败仍然应该使测试成功是很奇怪的，但是编译器测试都是关于写下我们对工具链的假设的。

If we know that a specific feature or corner case currently isn’t supported on one platform, we make sure there is a test added which says so.

如果我们知道一个平台当前不支持特定功能或特殊情况，请确保添加了一个测试，说明是否如此。

This means that we can easily look up in our code which features are supported by our Toolchains. However, it will also let us know if this actually changes at some point as we update our Toolchains.

这意味着我们可以轻松地在我们的代码中查找工具链支持的功能。 但是，它也会让我们知道在更新工具链时，它是否确实在某个时候改变了。

This will also help the low level developers with their round-trip time for testing that changes compile on all platforms and that any compile time assertions are valid.

这还将帮助低级开发人员往返时间，以测试更改是否已在所有平台上编译以及所有编译时间声明是否有效。

The build system knows about our code base, so the developers can include the header files for what they have implemented and do extra assertions if necessary in t