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

106 lines
1.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.
Reference in New Issue Copy Permalink