Hi,
our product has a multi-dimensional configurability, i.e. there is parameter A, which can have values A1, A2, A3, A4 then there is parameter B which can be B1 or B2 and then there is Debug or Release build.
All combinations of A1B1 A1B2 A2B1, ... shall be buildable by our engineers and our CI build pipeline (in both Debug and Release configurations, ideally.)
Now the core differences are:
- All configurations have the same project-specific include paths and library linkage paths
- Debug and Release configurations differ slightly in include and library paths which go to TI-supplied libraries, though. (because there are debug and release variants of these libraries)
- B1 and B2 differ in doing `#define FOO_B1` or `#define FOO_B2`, respectively.
- A1, ..., A4 differ in doing `#define A_VALUE 1` (or 2, ..., 4, respectively)
It is very tedious to maintain one build configuration for every possible combination of these variants. Especially when include paths or compiler options change due to new modules being added, or due to optimizations and tinkering with build flags.
I found the following possible solutions, all of which don't really fit our purpose:
- Creating a `config.h` file which contains the An and Bn defines. Maintain only a Release and a Debug build configuration, and do the configuration by altering the config.h file. While this is easy to use for developers, it is hard to integrate into a CI pipeline context. Also, it is hard to trace which build artifact was built with which configuration
- Using environment variables for A and B variants, and maintaining only Release and Debug build configurations. This would be at least easier for the CI pipeline, but unusable for our developers, since they would need to launch CCS from the command line, with manually setting some env variables before.
What would be an easier solution to maintain this configurability while reducing the overhead of having to do the same change in 4*2*2 = 16 different build configs every time?
