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 13:32:58 +02:00
|
|
|
# kas - setup tool for bitbake based projects
|
|
|
|
#
|
|
|
|
# Copyright (c) Siemens AG, 2017
|
|
|
|
#
|
|
|
|
# Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
# of this software and associated documentation files (the "Software"), to deal
|
|
|
|
# in the Software without restriction, including without limitation the rights
|
|
|
|
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
# copies of the Software, and to permit persons to whom the Software is
|
|
|
|
# furnished to do so, subject to the following conditions:
|
|
|
|
#
|
|
|
|
# The above copyright notice and this permission notice shall be
|
|
|
|
# included in all copies or substantial portions of the Software.
|
|
|
|
#
|
|
|
|
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
|
|
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
# SOFTWARE.
|
|
|
|
|
|
|
|
"""
|
|
|
|
This module implements how includes of configuration files are handled in
|
|
|
|
kas.
|
|
|
|
"""
|
|
|
|
|
|
|
|
import os
|
|
|
|
import collections
|
|
|
|
import functools
|
|
|
|
import logging
|
2017-06-21 13:33:00 +02:00
|
|
|
|
2017-07-17 22:38:05 +02:00
|
|
|
from . import __file_version__, __compatible_file_version__
|
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 13:32:58 +02:00
|
|
|
|
|
|
|
__license__ = 'MIT'
|
|
|
|
__copyright__ = 'Copyright (c) Siemens AG, 2017'
|
|
|
|
|
|
|
|
|
2017-07-05 16:27:39 +02:00
|
|
|
class LoadConfigException(Exception):
|
|
|
|
"""
|
|
|
|
Class for exceptions that appear while loading the configuration file.
|
|
|
|
"""
|
2017-07-11 07:57:37 +02:00
|
|
|
def __init__(self, message, filename):
|
|
|
|
super().__init__('{}: {}'.format(message, filename))
|
2017-07-05 16:27:39 +02:00
|
|
|
|
|
|
|
|
2017-06-21 13:33:00 +02:00
|
|
|
def load_config(filename):
|
|
|
|
"""
|
|
|
|
Load the configuration file and test if version is supported.
|
|
|
|
"""
|
|
|
|
(_, ext) = os.path.splitext(filename)
|
|
|
|
config = None
|
|
|
|
if ext == '.json':
|
|
|
|
import json
|
|
|
|
with open(filename, 'rb') as fds:
|
|
|
|
config = json.load(fds)
|
|
|
|
elif ext == '.yml':
|
|
|
|
import yaml
|
|
|
|
with open(filename, 'rb') as fds:
|
|
|
|
config = yaml.safe_load(fds)
|
|
|
|
else:
|
2017-07-05 16:27:39 +02:00
|
|
|
raise LoadConfigException('Config file extension not recognized',
|
|
|
|
filename)
|
2017-06-21 13:33:00 +02:00
|
|
|
|
2017-07-05 16:27:39 +02:00
|
|
|
try:
|
|
|
|
header = config.get('header', {})
|
|
|
|
except AttributeError:
|
|
|
|
raise LoadConfigException('Config does not contain a dictionary',
|
|
|
|
filename)
|
|
|
|
|
|
|
|
if not header:
|
|
|
|
raise LoadConfigException('Header missing or empty', filename)
|
|
|
|
|
|
|
|
try:
|
2017-07-17 22:38:05 +02:00
|
|
|
version = header.get('version', None)
|
2017-07-05 16:27:39 +02:00
|
|
|
except AttributeError:
|
|
|
|
raise LoadConfigException('Header is not a dictionary', filename)
|
2017-06-21 13:33:00 +02:00
|
|
|
|
2017-07-17 22:38:05 +02:00
|
|
|
if not version:
|
2017-07-05 16:27:39 +02:00
|
|
|
raise LoadConfigException('Version missing or empty', filename)
|
2017-06-21 13:33:00 +02:00
|
|
|
|
|
|
|
try:
|
2017-07-17 22:38:05 +02:00
|
|
|
version_value = int(version)
|
2017-06-21 13:33:00 +02:00
|
|
|
except ValueError:
|
2017-07-17 22:38:05 +02:00
|
|
|
# Be compatible: version string '0.10' is equivalent to file version 1
|
|
|
|
if isinstance(version, str) and version == '0.10':
|
|
|
|
version_value = 1
|
|
|
|
else:
|
|
|
|
raise LoadConfigException('Unexpected version format', filename)
|
|
|
|
|
|
|
|
if version_value < __compatible_file_version__ or \
|
|
|
|
version_value > __file_version__:
|
|
|
|
raise LoadConfigException('This version of kas is compatible with '
|
|
|
|
'version {} to {}, file has version {}'
|
|
|
|
.format(__compatible_file_version__,
|
|
|
|
__file_version__, version_value),
|
|
|
|
filename)
|
2017-06-21 13:33:00 +02:00
|
|
|
|
|
|
|
return config
|
|
|
|
|
|
|
|
|
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 13:32:58 +02:00
|
|
|
class IncludeException(Exception):
|
|
|
|
"""
|
|
|
|
Class for exceptions that appear in the include mechanism.
|
|
|
|
"""
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
|
|
class IncludeHandler(object):
|
|
|
|
"""
|
|
|
|
Abstract class that defines the interface of an include handler.
|
|
|
|
"""
|
|
|
|
|
|
|
|
def __init__(self, top_file):
|
|
|
|
self.top_file = top_file
|
|
|
|
|
|
|
|
def get_config(self, repos=None):
|
|
|
|
"""
|
|
|
|
Parameters:
|
|
|
|
repos -- A dictionary that maps repo name to directory path
|
|
|
|
|
|
|
|
Returns:
|
|
|
|
(config, repos)
|
|
|
|
config -- A dictionary containing the configuration
|
|
|
|
repos -- A list of missing repo names that are needed \
|
|
|
|
to create a complete configuration
|
|
|
|
"""
|
|
|
|
# pylint: disable=no-self-use,unused-argument
|
|
|
|
|
|
|
|
logging.error('get_config is not implemented')
|
2017-07-05 16:27:39 +02:00
|
|
|
raise NotImplementedError()
|
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 13:32:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
class GlobalIncludes(IncludeHandler):
|
|
|
|
"""
|
|
|
|
Implements a handler where every configuration file should
|
|
|
|
contain a dictionary as the base type with and 'includes'
|
|
|
|
key containing a list of includes.
|
|
|
|
|
|
|
|
The includes can be specified in two ways, as a string
|
|
|
|
containg the relative path from the current file or as a
|
|
|
|
dictionary. The dictionary should have a 'file' key, containing
|
|
|
|
the relative path to the include file and optionally a 'repo'
|
|
|
|
key, containing the key of the repository. If the 'repo' key is
|
|
|
|
missing the value of the 'file' key is threated the same as if
|
|
|
|
just a string was defined, meaning the path is relative to the
|
|
|
|
current config file otherwise its relative to the repository path.
|
|
|
|
|
|
|
|
The includes are read and merged depth first from top to buttom.
|
|
|
|
"""
|
|
|
|
|
|
|
|
def get_config(self, repos=None):
|
|
|
|
repos = repos or {}
|
|
|
|
|
|
|
|
def _internal_include_handler(filename):
|
|
|
|
"""
|
|
|
|
Recursively load include files and find missing repos.
|
|
|
|
|
|
|
|
Includes are done in the following way:
|
|
|
|
|
|
|
|
topfile.yml:
|
|
|
|
-------
|
2017-06-21 13:32:59 +02:00
|
|
|
header:
|
|
|
|
includes:
|
|
|
|
- include1.yml
|
|
|
|
- file: include2.yml
|
|
|
|
- repo: repo1
|
|
|
|
file: include-repo1.yml
|
|
|
|
- repo: repo2
|
|
|
|
file: include-repo2.yml
|
|
|
|
- include3.yml
|
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 13:32:58 +02:00
|
|
|
-------
|
|
|
|
|
|
|
|
Includes are merged in in this order:
|
|
|
|
['include1.yml', 'include2.yml', 'include-repo1.yml',
|
|
|
|
'include-repo2.yml', 'include-repo2.yml', 'topfile.yml']
|
|
|
|
On conflict the latter includes overwrite previous ones and
|
|
|
|
the current file overwrites every include. (evaluation depth first
|
|
|
|
and from top to buttom)
|
|
|
|
"""
|
|
|
|
missing_repos = []
|
|
|
|
configs = []
|
2017-06-21 13:33:00 +02:00
|
|
|
current_config = load_config(filename)
|
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 13:32:58 +02:00
|
|
|
if not isinstance(current_config, collections.Mapping):
|
|
|
|
raise IncludeException('Configuration file does not contain a '
|
|
|
|
'dictionary as base type')
|
2017-06-21 13:32:59 +02:00
|
|
|
header = current_config.get('header', {})
|
|
|
|
|
|
|
|
for include in header.get('includes', []):
|
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 13:32:58 +02:00
|
|
|
if isinstance(include, str):
|
|
|
|
includefile = ''
|
|
|
|
if include.startswith(os.path.pathsep):
|
|
|
|
includefile = include
|
|
|
|
else:
|
|
|
|
includefile = os.path.abspath(
|
|
|
|
os.path.join(
|
|
|
|
os.path.dirname(filename),
|
|
|
|
include))
|
|
|
|
(cfg, rep) = _internal_include_handler(includefile)
|
|
|
|
configs.extend(cfg)
|
|
|
|
missing_repos.extend(rep)
|
|
|
|
elif isinstance(include, collections.Mapping):
|
|
|
|
includerepo = include.get('repo', None)
|
|
|
|
if includerepo is not None:
|
|
|
|
includedir = repos.get(includerepo, None)
|
|
|
|
else:
|
|
|
|
raise IncludeException(
|
|
|
|
'"repo" is not specified: {}'
|
|
|
|
.format(include))
|
|
|
|
if includedir is not None:
|
|
|
|
try:
|
|
|
|
includefile = include['file']
|
|
|
|
except KeyError:
|
|
|
|
raise IncludeException(
|
|
|
|
'"file" is not specified: {}'
|
|
|
|
.format(include))
|
|
|
|
(cfg, rep) = _internal_include_handler(
|
|
|
|
os.path.abspath(
|
|
|
|
os.path.join(
|
|
|
|
includedir,
|
|
|
|
includefile)))
|
|
|
|
configs.extend(cfg)
|
|
|
|
missing_repos.extend(rep)
|
|
|
|
else:
|
|
|
|
missing_repos.append(includerepo)
|
|
|
|
configs.append((filename, current_config))
|
|
|
|
return (configs, missing_repos)
|
|
|
|
|
|
|
|
def _internal_dict_merge(dest, upd, recursive_merge=True):
|
|
|
|
"""
|
|
|
|
Merges upd recursively into a copy of dest as OrderedDict
|
|
|
|
|
|
|
|
If recursive_merge=False, will use the classic dict.update,
|
|
|
|
or fall back on a manual merge (helpful for non-dict types
|
|
|
|
like FunctionWrapper)
|
|
|
|
"""
|
|
|
|
if (not isinstance(dest, collections.Mapping)) \
|
|
|
|
or (not isinstance(upd, collections.Mapping)):
|
|
|
|
raise IncludeException('Cannot merge using non-dict')
|
|
|
|
dest = collections.OrderedDict(dest)
|
|
|
|
updkeys = list(upd.keys())
|
|
|
|
if not set(list(dest.keys())) & set(updkeys):
|
|
|
|
recursive_merge = False
|
|
|
|
if recursive_merge:
|
|
|
|
for key in updkeys:
|
|
|
|
val = upd[key]
|
|
|
|
try:
|
|
|
|
dest_subkey = dest.get(key, None)
|
|
|
|
except AttributeError:
|
|
|
|
dest_subkey = None
|
|
|
|
if isinstance(dest_subkey, collections.Mapping) \
|
|
|
|
and isinstance(val, collections.Mapping):
|
|
|
|
ret = _internal_dict_merge(dest_subkey, val)
|
|
|
|
dest[key] = ret
|
|
|
|
else:
|
|
|
|
dest[key] = upd[key]
|
|
|
|
return dest
|
2017-06-28 14:48:40 +02:00
|
|
|
try:
|
|
|
|
for k in upd:
|
|
|
|
dest[k] = upd[k]
|
|
|
|
except AttributeError:
|
|
|
|
# this mapping is not a dict
|
|
|
|
for k in upd:
|
|
|
|
dest[k] = upd[k]
|
|
|
|
return dest
|
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 13:32:58 +02:00
|
|
|
|
|
|
|
configs, missing_repos = _internal_include_handler(self.top_file)
|
|
|
|
config = functools.reduce(_internal_dict_merge,
|
|
|
|
map(lambda x: x[1], configs))
|
|
|
|
return config, missing_repos
|