In order to properly handle different styles of build (debug, release, etc) as well as different platform targets to build on (x86, x86_64, ARM, VHDL standards, etc. etc.), a way to group these different build modes shall be designed.
These will be so-called Build Contexts.
Each context is a list of tags, with each tag then being used to configure the build system.
Configuration parameters would be based on a "default" context that provides standard parameters, with each tag activating extra configurations that are overlaid onto the configuration.
Example:
The debug tag will append certain compiler options to e.g. set optimization levels and debug options. The tag x86 would activate configurations for that machine architecture, and so on.
Each BuildContext would get its own build directory, based on a sorted and joined taglist. Tags x86 and debug could be joined to debug_x86, forming the build dir build/debug_x86.
An empty list of tags would instead use default
Certain BuildContext tags could be made exclusive or mandatory, such as avoiding debug_release.
BuildContext would be automatically inherited from the creating Artefact to ease implementation. However, cross-context Artefact requirements shall be made possible, to allow for e.g. automatic "Build in debug mode, test, then build in release mode" runs, as well as having multi-architecture builds or hybrid architecture builds (such as building an STM32 firmware that includes binaries for an FPGA)
BuildContext configuration overlaying would be done by having the config file be DSL Ruby Files. Each file could register a set of configurations to apply for certain tag combinations, as well as the priority for each configuration snippet.
Configuration overlays would then be applied according to priority, to generate a finalized output configuration. This could be a bit slow, as each build file may need a individualized configuration generation, but as executing Ruby code should be faster than the actual compilation, this should be a valid strategy and allow for highly customizeable and flexible designs.
The Root Build Context will also be used to configure things such as Resource Locations to search for files and other global configuration options.