嵌入式构建系统的配置和检查
如果你曾经开发过嵌入式软件，你就会知道典型的嵌入式构建系统只有两种构建配置：调试和发布。事实上，你可能大部分时间都只使用调试构建。Rust构建系统在测试中走得更远。但是，你知道有五种基本的构建配置应该使用吗?让我们探讨一下你和你的嵌入式开发团队可以使用的不同嵌入式构建系统配置，以确保你更快地开发软件。
构建系统配置1—分析
我们要讨论的第一个嵌入式构建系统配置是分析构建。开发高质量的嵌入式软件需要你审查和分析你的软件。你应该问这样的问题：
l我的函数的圈复杂度是多少?
l我的代码的耦合性是什么?
l我的任务是否以正确的下次速度执行?
l我最差的CPU负载是多少?
l我是否通过了正确性和编码标准的静态代码分析测试?
许多构建时检查可以在代码上执行，通常委托给手工评审或者推给CI/CD。通常，在提交代码之前，我会运行我的分析构建。构建将运行我所有的静态、动态和度量检查，以确保我的代码处于提交到DevOps系统的正确状态。
构建系统配置2—模拟
模拟应用程序代码是开发嵌入式软件最没有得到充分利用的技术。你的构建系统应该具有允许你在你的主机环境上构建模拟软件的配置。你不一定需要一个目标模拟器;你可以通过在主机上运行应用程序代码来验证它。模拟有很多优点，例如：
l提高了时间效率——你不必等待硬件的到来，无需franken-boards，并且消除了bug-flash-debug循环。
l灵活性和可扩展性–你必须使用硬件抽象层(HALs)分离代码并提高可重用性。
l降低开发成本–在主机环境中调试和解决问题的速度比在嵌入式目标上更快。
嵌入式开发人员通常认为他们不能模拟他们的软件，因为它接触到了硬件。然而，精心制作的软件架构可以实现模拟和目标执行。此外，像DevOps的CI/CD技术这样的现代技术迫使许多团队重新思考他们如何设计他们的软件来更好地管理他们的硬件依赖。所以如果你追求DevOps，增加一个模拟构建是很自然的扩展。
构建系统配置3—测试
如果你一直致力于现代化你的嵌入式软件过程，那么你可能已经遇到或创建了你的测试构建配置。测试配置是关于运行单元测试、集成测试，甚至可能是系统级测试(尽管我通常把它推到CI/CD过程中)。
当你创建一个测试构建配置时，你将集成一个运行该构建的测试工具。测试工具通常为你的主机编译，而不是为你的目标编译，但是这取决于你的需要。与模拟一样，你需要一个良好的HAL和解耦来在主机上测试你的应用程序代码。不过，要小心;单元测试不是模拟。模拟就是在主机上运行代码，就像在目标上一样。单元测试是关于运行单独的受控测试，以确保单个模块按预期工作。
构建系统配置5—调试
调试配置是你久经考验的嵌入式构建系统配置。如果你在一个工程部门的地板上走来走去，你经常会发现嵌入式开发人员愉快地单步调试他们的软件代码。不幸的是，这可能是一个嵌入式开发人员在大多数时候所能做的最糟糕的事情(有时，这种调试时间是必要的)。
调试版本通常在映像中包含更多的信息，因此开发人员可以四处查看并进行调试。问题是大多数应用程序代码可以在主机上调试得更好。调试构建通常会降低开发人员的速度，并鼓励糟糕的调试实践。它们对于驱动开发来说是不可避免的，但是大多数团队都在使用他们芯片供应商的驱动代码，所以使用一个好的HAL，你就可以模拟或者测试你的bug。
嵌入式构建系统结论
调试构建配置并不是嵌入式软件团队唯一可用的配置。事实上，希望你已经意识到，分析、测试和模拟构建配置的使用可能更有价值和效率。诀窍是将嵌入式软件和固件仅仅视为软件。与在嵌入式开发目标上相比，在MacOS、Linux或Windows上测试适当分层、分离和抽象的应用程序代码更容易。希望你仔细考虑这些构建配置，并制定一个行动计划，开始将它们集成到你的构建过程中。
