PTU5KAS/kas
Claudius Heine 34dd07e76e added initial implementation of a include handler
Splitting configuration files into multiple files and implementing an
include mechanism allows to handle configurations more flexible and
allowing following scenarios:

 - including kas configuration file from external meta layer into
   own project
 - splitting many different similar configurations into multiple files
   with only a couple of common files

To include file its necessary to add a 'includes' entry into the kas
configuration. To include files from the same repo, do it like this:

-----
includes:
  - ../base/base_include.yml
-----

The path is relative to the current configuration file. If they start
with a path seperator ("/") they are absolute.

To include files from a different repository, do it like this:

-----
includes:
  - file: bsps/my_machine_include.yml
    repo: collected_machines

repos:
  collected_machines:
    url: https://url.to.git.repo/
    revspec: master
-----

You have to make sure that the repository definition is available
in your current file, or in any include that is available at this
point.

Yaml ("*.yml") and Json ("*.json") files are supported.

Included in this patch are also some changes to the configuration
file structure. Here is an overview:

The value of the 'repos' key is a dictionary that maps a repo identifier
to a dictionary that contains 5 entries:

- url: The url to the repository. If that is missing, no git operations
are used
- refspec: The git refspec of the repository that is used. If that is
missing the latest commit of the default branch is used.
- name: The is defines under which name the repository is stored. If
that is missing the repository identifier is used
- path: The path where the repository is stored. If no url is given and
a path is missing, the repository is referencing the repository under
which the configuration file is stored. If no url is given and a path is
specified, the repository is referencing a directory where layers might
be stored. If an url is specified, path can be used to overwrite the
default (kas_work_dir + repo.name) checkout directory.
- layers: This contains a dictionary of layers, that should be included
into the bblayers.conf. The keys are paths relative to the repository
and the values can be used to exclude layers if they are one of
"excluded", "disabled", "false", "0", "n", or "no". Also boolean values
are accepted. Any other value, including "None" means that this layer is
included into the bblayers.conf. If "layers" is missing or empty, the
repository itself is included into the bblayers. If this is specified, the
repository itself is not included into the bblayers.conf.

Signed-off-by: Claudius Heine <ch@denx.de>
2017-06-21 17:30:51 +02:00
..
__init__.py run pylint3 and fixed report 2017-06-21 17:30:51 +02:00
__main__.py run pylint3 and fixed report 2017-06-21 17:30:51 +02:00
__version__.py run pylint3 and fixed report 2017-06-21 17:30:51 +02:00
build.py run pylint3 and fixed report 2017-06-21 17:30:51 +02:00
config.py added initial implementation of a include handler 2017-06-21 17:30:51 +02:00
includehandler.py added initial implementation of a include handler 2017-06-21 17:30:51 +02:00
kas.py run pylint3 and fixed report 2017-06-21 17:30:51 +02:00
libcmds.py run pylint3 and fixed report 2017-06-21 17:30:51 +02:00
libkas.py run pylint3 and fixed report 2017-06-21 17:30:51 +02:00
repos.py Renamed sublayers back to layers 2017-06-21 17:30:51 +02:00
shell.py run pylint3 and fixed report 2017-06-21 17:30:51 +02:00