SiegfriedSiegert/PTU5KAS
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
e274886ab0
PTU5KAS/docs/format-changelog.rst

143 lines
2.6 KiB
ReStructuredText
Raw Normal View History

Switch to separate config file version Use a separately incremented integer to track the configuration file format version. We start with 2 due to the change that 23c3a951f6e4 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>
2017-07-17 22:38:05 +02:00
Configuration Format Changes
============================
Version 1 (Alias '0.10')
------------------------
Added
~~~~~
- Include mechanism
- Version check
Version 2
---------
Changed
~~~~~~~
- Configuration file versions are now integers
Fixed
~~~~~
- Including files from repos that are not defined in the current file
docs/format-changelog.rst: Updated to include the recent changes 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>
2017-10-16 10:44:11 +02:00
Version 3
---------
Added
~~~~~
- ``Task`` key that allows to specify which task to run (``bitbake -c``)
Version 4
---------
Added
~~~~~
- ``Target`` key now allows to be a list of target names
multiconfig: implement initial support 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>
2017-11-07 17:20:17 +01:00
Version 5
---------
Changed behavior
~~~~~~~~~~~~~~~~
- Using ``multiconfig:*`` targets adds appropriate ``BBMULTICONFIG`` entries to
the ``local.conf`` automatically.
implementation of environment variable passthrough 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>
2017-11-23 14:15:51 +01:00
Version 6
---------
Added
~~~~~
- ``env`` key now allows to pass custom environment variables to the bitbake
build process.
repos: introduce a new repo conf parameter "type" 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>
2018-01-05 16:00:28 +01:00
Version 7
---------
Added
~~~~~
- ``type`` property to ``repos`` to be able to express which version control
system to use.
implements patch support for repos 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>
2018-03-09 08:22:52 +01:00
Version 8
---------
Added
~~~~~
- ``patches`` property to ``repos`` to be able to apply additional patches to
the repo.
config: Allow a default refspec to be specified 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>
2020-07-04 09:53:38 +02:00
Version 9
---------
Added
~~~~~
- ``defaults`` key can now be used to set a default value for the repository
config: Allow a default repo to be specified for patches Signed-off-by: Paul Barker <pbarker@konsulko.com> [Jan: style fix] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2020-07-04 09:53:39 +02:00
property ``refspec`` and the repository patch property ``repo``. These
default values will be used if the appropriate properties are not defined
for a given repository or patch.
Add build_system property to config file 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>
2020-11-15 09:57:51 +01:00
Version 10
----------
Added
~~~~~
- ``build_system`` property to pre-select OE or Isar.
Bump format revision due to changes to include paths This justifies a version bump, even though the old behavior is still supported. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2021-10-09 14:37:45 +02:00
Version 11
----------
Changed behavior
~~~~~~~~~~~~~~~~
- String item ``includes`` are now using repo-relative paths. File-relative is
still supported by issues a deprecation warning.
libcmds: Write more bblayers.conf boilerplate settings 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>
2021-10-11 08:10:29 +02:00
- bblayers.conf is generated with ``BBPATH`` and ``BBFILES`` preset to common
defaults. Those can still be overwritten via ``bblayers_conf_headers``.
Add kconfiglib-based menu plugin 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>
2021-07-10 11:25:13 +02:00
Added
~~~~~
- ``menu_configuration`` key stores the selections done via ``kas menu`` in a
configuration file. It is only evaluated by that plugin.
Allow "deleting" url/path of repo in override 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>
2022-04-06 12:16:38 +02:00
Version 12
----------
Added
~~~~~
- For repositories, ``url`` and ``path`` can now be overridden with a
null-value to switch between version-controlled repositories and unversioned
local folders.
add conditional environment variables 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>
2022-11-10 13:46:45 +01:00
Version 13
----------
Added
~~~~~
- Variables used in the ``env`` section can now be assigned 'None' as value. In
this case the variables are only exported to the bb env whitelist.
add support to override refspec of repos This patch adds the top-level `overrides` entry, which is used to override (or pin) the refspec of repositories. The main difference to a direct override is that this logic only applies to repos that are already defined. By that, a superset of all repos can be added to this entry (similar to a global lockfile), but only the currently active ones are affected. A new top-level keyword is required because everything below the "repos" keyword is potentially defined by "default" values. For the locking mechanism, a clear separation between overrides (only override if existing) and definitions is required to be able to define a global lockfile with all possible repos, while just defining some repos. Proposed-by: Ross Burton <ross@burtonini.com> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com> [Jan: also bump __file_version__] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2023-04-23 11:42:25 +02:00
Version 14
----------
Added
~~~~~
- The ``overrides`` top-level entry can be used to pin floating repo refspecs.
menu plugin: track root repo dir This patch adds a new top-level schema node `_source_dir` which is used to track the top repo dir on auto-generated kas files. This node is generated by the kas menu plugin and provides the absolute path to the top repo dir at time of invoking the plugin. When later calling any other kas operation that performs a checkout, this node is evaluated and the top repo dir is set accordingly. This tracking is required when the build command is executed from another dir than the top repo dir, as the repo-dir cannot be computed by kas in this case (the .config.yaml file is in the KAS_WORK_DIR, not in the repo dir). Proposed-by: Peter Hoyes <Peter.Hoyes@arm.com> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com> [Jan: aligned format-changelog text, simplified load_config returning] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2023-05-26 06:39:42 +02:00
- ``_source_dir`` top-level entry is auto-generated when using the menu plugin
and provides the path to the top repo at time of invoking the plugin.
Reference in New Issue Copy Permalink