This allows to pre-select the build system, specifically avoiding
confusion when kas-container is accidentally not called with --isar for
an isar config. For that, build_system needs to be defined in the
lop-level config file passed to kas-container.
Theoretically, this also allows to combine layers which have both
oe-init-build-env and isar-init-build-env scripts.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Also update config file version to 9 due to this format change.
Signed-off-by: Paul Barker <pbarker@konsulko.com>
[Jan: style fix]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
With this commit its now possible to patch 3rd party repos before bitbake is started.
Example:
This is our repo:
.
├── kas.yml
├── first-patch.patch
└── quilt-patches
├── second-patch.patch
├── third-patch.patch
└── series
Content of kas.yml:
header:
version: 8
repos:
my:
third-party:
url: "git://example.com/third-party.git"
refspec: "35adf4...34"
patches:
01-first:
repo: my
path: "first-patch.patch"
02-second:
repo: my
path: "quilt-patches"
Currently only 'git' repositories can be patched.
Signed-off-by: Claudius Heine <ch@denx.de>
This will be used to carry the type of repo we are talking about. At the
moment it defaults to "git".
Signed-off-by: Henning Schild <henning.schild@siemens.com>
With this its possible to create custom environment variables within the kas
configuration file, that are passed through to the build environment:
env:
VARIABLE_NAME: "default variable value"
Those variables can be overwritten by variables of the environment kas is
started in:
$ VARIABLE_NAME="overwritten variable value" kas shell ...
Those variables are also added to the 'BB_ENV_EXTRAWHITE' variable list to make
them available to bitbake.
This is useful for instance storing sensitive information, that should not be
part of the configuration files or bitbake recipes.
Signed-off-by: Claudius Heine <ch@denx.de>
This patch adds multiconfig support to kas by defining the
"BBMULTICONFIG" variable in the "local.conf" file.
Signed-off-by: Claudius Heine <ch@denx.de>
Since its easy to forget to update the documentation when changing the
configuration file format version, this patch adds a small note to
remind the developer about it.
Signed-off-by: Claudius Heine <ch@denx.de>
With this patch support for building multiple targets in parallel with
bitbake is now supported.
Changes:
- Its now possible to state a list of targets under the target key in
the configuration file.
Example:
target:
- product-image
- product-update-image
- Its now possible to define multiple targets in the kas command line.
Example:
$ kas build --target product-image --target product-update-image \
kas.yml
- Its now possible to define multiple targets via the environment:
Example:
$ export KAS_TARGET="product-image product-update-image"
$ kas build kas.yml
Signed-off-by: Claudius Heine <ch@denx.de>
Captain Hindsight: We should have never committed 13a87cb8c7 ("Allow
to define task in config and environment") without forwarding the file
version. Without this, no config file writer can tell kas versions
apart that support task control from those that don't.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Use a separately incremented integer to track the configuration file
format version. We start with 2 due to the change that 23c3a951f6
introduced. 1 is declared to be equivalent to the original '0.10'.
The separate versioning has the advantage of being able to increment it
already during the development cycle, and using it with config files
that test/exploit the new format.
Using an integer has the advantages of a) differentiating it clearly
from the now independent kas version and b) simplifying the version
parsing. We can now also remove the string type restriction.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
If the configuration file structure changes over time, it might
introduce incompatibilities.
This patch introduces versioning of configuration file.
Configuration files needs to add a 'version' entry into their 'header'
like this:
header:
version: '0.9'
After loading this file, the version is checked agains kas version.
Every version 'M.m.p' of kas is allowed to load configuration files with
version 'M.m' and all versions backwards up to and including
the '__compatible_version__' from kas/__version__.py
Signed-off-by: Claudius Heine <ch@denx.de>
