Until now all environment variables in the kas config's
env section require a default value.
In some cases we want to rely on the weak assignment
of bitbake instead of relying on the default value of the
variable in the kas config.
This means if we assign the 'None' value or nothing to the variable
in the kas config then it is only added to BB_ENV_EXTRAWHITE or
BB_ENV_PASSTHROUGH_ADDITIONS without setting it as environment
variable.
Signed-off-by: Benedikt Niedermayr <benedikt.niedermayr@siemens.com>
[Jan: fixed overlong line]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Make "null" an allowed type for the `url` and `path` properties of a
repository. This allows "deleting" them in an override kas-file to e.g.
point a repository at a local directory instead of a git remote:
"Original" file:
repos:
meta-foo:
url: https://example.org/foo.git
refspec: badc0ffee
Override:
repos:
meta-foo:
url:
path: /path/to/local/foo
Without the explicit "nulling" of the URL, kas would start messing with
the repo in /path/to/local/foo (changing remote URL, switching to a
different rev, etc.). With this change, we can instead force kas to use
the recipes in that directory untouched.
Signed-off-by: Harald Seiler <hws@denx.de>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Irrespective of build system (OE / Yocto / Isar), they all have
BBPATH = "${TOPDIR}"
BBFILES ?= ""
in their bblayers_conf_header fragments. This could be dropped if kas
wrote those standard assignments already. So let's do that, weakly so
that those could still be overwritten via bblayers_conf_header.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This uses the kconfiglib python module to implement simple interactive
configuration for complex layers with many kas options and even variable
input. See the menu.py documentation header for details on the Kconfig
format and its translation to kas.
Rather than using the limited menuconfig implementation of kconfiglib,
this comes with an own, python-newt based version. The permits smooth
integration in the workflow, e.g. to offer an option that directly
triggers a build after completing a configuration. And it comes with a
nicer layout.
Unfortunately, python-newt can't be fulfilled via pip. But it is
available as proper package via common distros. So warn if the package
is missing.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
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>
This patch updated the 'docs/format-changelog.rst' file to include
information about the configuration file version 3 and 4.
Signed-off-by: Claudius Heine <ch@denx.de>
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>
