[参考译文] 管理编译配置的多维矩阵

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1311919/managing-a-multi-dimensional-matrix-of-build-configurations

您好！

我们的产品具有多维可配置性、即参数 A、它可以具有值 A1、A2、A3、A4、还有参数 B、可以是 B1或 B2、然后是 Debug 或 Release 构建。

所有的组合 A1B1 A1B2 A2B1 ,... 应可由我们的工程师和我们的 CI 构建流水线构建(理想情况下、在 Debug 和 Release 配置中)。

现在、核心差异为：

• 所有配置都具有相同的工程特定包含路径和库链接路径
• 但是、调试和发布配置在进入 TI 提供的库的包含路径和库路径上略有不同。 (因为这些库具有调试和发布变体)
• B1和 B2在分别执行`#define foo_B1`或`#define foo_B2`方面有所不同。
• A1、...、A4在执行`#define A_value 1`(或分别为2、...、4)方面存在差异

为这些变体的每个可能组合维护一个编译配置是非常乏味的。 尤其是添加新模块或由于优化和修整构建标志而导致包含路径或编译器选项更改时。

我找到了以下可能的解决方案、所有这些解决方案都不符合我们的目的：

• 创建一个`config.h`文件、该文件包含 AN 和 Bn 定义。 仅保留 Release 和 Debug 编译配置、并通过更改 config.h 文件进行配置。 虽然这对开发人员来说很容易使用、但很难集成到 CI 流水线上下文中。 此外、很难跟踪使用哪种配置构建的工件
• 将环境变量用于 A 和 B 变体、并且仅维护 Release 和 Debug 编译配置。 这对于 CI 流水线来说至少更容易、但对我们的开发人员来说无法使用、因为他们需要从命令行启动 CCS、之前需要手动设置一些 env 变量。

哪种更简单的解决方案可以保持这种可配置性，同时减少每次都必须在4*2*2=16个不同构建配置中进行相同更改的开销？