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

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