The buildConfigurations definitions
Purpose
Define a map of build configurations.
Syntax
{
...
"buildConfigurations": {
...
"<build configuration name>": {
...
"hidden": true,
"inherit": [ "<build configuration name>",... ],
"dependencies": { ... },
"devDependencies": { ... },
"properties": {
...
"<property name>": "<property value",
...
},
"actions": {
...
"<action name>": "<command>" | [ "<command>",... ],
...
}
...
}
}
}
Description
During development, it is usual to build separate debug and release binaries, with different configurations, such as preprocessor macros, compiler options, and optimisation levels.
Extensive testing also requires building separate binaries, potentially targeting different architectures, and using different toolchains, or even different versions of the same toolchain.
Build configurations address this need by allowing the definition multiple different actions to run different builds and/or tests.
Build configurations can define their own properties, actions,
definitions and devDefinition
which take precedence over definitions with the same names defined at
the project level.
To avoid redundant definitions, build configurations can inherit
properties, actions, definitions and devDefinition
from one or more other build configurations,
and redefine some of them, as needed.
Properties
hidden
This boolean property is to be used by IDEs and has no functional consequences.
The mechanism that allows one build con
inherit
The value of the inherit property is an array of strings with
build configuration names.
The current build configuration inherits definitions from all the build configurations listed by this property.
The inheritance strategy uses overrides, so last definition override previous ones.
The definition collection is done in the given order, followed by local definitions.
Other properties
Example
{
"xpack": {
"buildConfigurations": {
"common-dependencies": { "...": "..." },
"common-actions": { "...": "..." },
"common-actions-native": { "...": "..." },
"common-docker": { "...": "..." },
"darwin-x64": {
"inherit": [
"common-dependencies",
"common-actions",
"common-actions-native"
],
"devDependencies": {
"@xpack-dev-tools/clang": "16.0.6-1.1",
"@xpack-dev-tools/realpath": "9.4.0-1.1",
"@xpack-dev-tools/sed": "4.9.0-3.1"
},
"actions": {
"build": "caffeinate {{properties.commandBashBuild}}",
"build-development": "caffeinate {{properties.commandBashBuild}} --develop",
"build-development-debug": "caffeinate {{properties.commandBashBuild}} --develop --debug",
"build-development-tests-only": "caffeinate {{properties.commandBashBuild}} --develop --tests-only"
}
},
"darwin-arm64": {
"inherit": [
"darwin-x64"
]
},
"linux-x64": {
"inherit": [
"common-dependencies",
"common-actions",
"common-actions-native",
"common-docker"
],
"devDependencies": {
"@xpack-dev-tools/gcc": "13.2.0-2.1",
"@xpack-dev-tools/patchelf": "0.18.0-1.1"
},
"properties": {
"dockerImage": "ilegeul/ubuntu:amd64-18.04-xbb-v5.2.2"
}
},
"linux-arm64": {
"inherit": [
"linux-x64"
],
"properties": {
"dockerImage": "ilegeul/ubuntu:arm64v8-18.04-xbb-v5.2.2"
}
},
"linux-arm": {
"inherit": [
"linux-x64"
],
"properties": {
"dockerImage": "ilegeul/ubuntu:arm32v7-18.04-xbb-v5.2.2",
"force32": "linux32"
}
}
}
}
}
The "hidden": true definition can be used by GUI tools
(like Visual Studio Code) to filter out
internal definition when rendering trees of action, for example.