Clear the output variable with an empty string, before appending to it.
Unsetting the variable locally is insufficient, because its value from
the parent scope or cache can still creep into the final result.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
According to the doc comment:
If using MERGE then SYSBUILD GLOBAL will get both the local and global
sysbuild scope variables (in that order, if both exist).
This stopped working in commit 8460d91e32,
when support for `zephyr_get(... VAR <multiple-variables>)` was added.
Instead of returning both values, the local sysbuild scope value would
clobber the global one. Fix this by splitting the internal `sysbuild`
scope into `sysbuild_local` and `sysbuild_global`, in that order.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
As `zephyr_get()` grows in complexity and significance, it must continue
working as expected. Unfortunately, it has a few minor bugs already, but
they will be taken care of in the next few commits. Before that, though,
let's go ahead and add a test suite for this function.
For now, some tests will pass by using incorrect values, annotated with
the `# BUG` comments; they will be removed in later patches. The purpose
of having them now is to make it easier to see what's about to be fixed.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
This commit reworks the snippet test to more comprehensively test the
different processing modes of snippets.
The following testcases have been added:
1. Initial state with no snippet applied
2. Applying `foo` snippet from the default application snippet root
3. Applying `bar` snippet from an extra snippet root
4. Sequentially applying `foo` and `bar` snippets to test the snippet
processing order
5. Sequentially applying `bar` and `foo` snippets to test the snippet
processing order.
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
This commit adds change snippets to use the new EXTRA_DTC_OVERLAY_FILE
and EXTRA_CONF_FILE Zephyr build system variables instead of
DTC_OVERLAY_FILE and OVERLAY_CONFIG.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Align Zephyr modules with other user facing variables where settings
can be defined or extended, meaning Zephyr modules now supports:
ZEPHYR_MODULES and EXTRA_ZEPHYR_MODULES.
Support for ZEPHYR_EXTRA_MODULES is kept foir backward compatibility.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Twister now supports using YAML lists for all fields that were written
as space-separated lists. Used twister_to_list.py script. Some artifacts
on string length are due to how ruamel dumps content.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add an initial test suite for the basic SNIPPET_ROOT, SNIPPET, and
'append' features in snippet.yml.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is an implementation of issue #48334 and adds support for
specifying additional config and device tree overlays through fields in
the testcase.yaml file, which is more readable than having to cram these
in to `extra_args`.
Consider this example which shows the original and new ways to add
config and DT overlays:
```
common:
extra_args: "CONF_FILE=a.conf;b.conf
DTC_OVERLAY_FILE=w.overlay;x.overlay OVERLAY_CONFIG=e.conf
UNRELATED=abc"
tests:
utilities.base64:
extra_conf_files:
- "c.conf"
- "d.conf"
extra_overlay_confs:
- "extra_overlay.conf"
extra_dtc_overlay_files:
- "y.overlay"
- "z.overlay"
extra_configs:
- CONFIG_SAMPLE=y
tags: base64
type: unit
```
The new fields are `extra_conf_files`, `extra_overlay_confs,
`extra_dtc_overlay_files`. Files specified in these sections are appended
to any `CONF_FILE`, `OVERLAY_CONFIG`, or `DTC_OVERLAY_FILE` fields in
`extra_args`, causing the following args being passed in to
`self.run_cmake` at `runner.py:850`:
```
['-DUNRELATED=abc',
'-DCONF_FILE=a.conf;b.conf;c.conf;d.conf',
'-DDTC_OVERLAY_FILE=w.overlay;x.overlay;y.overlay;z.overlay',
'-DOVERLAY_CONFIG=e.conf extra_overlay.conf '
'<build_dir>/twister/testsuite_extra.conf']
```
These fields can be used in the common or scenario-specific YAML
sections and will be merged in order of least to most specific:
1. config files extracted from common's extra_args
2. files listed in common's {extra_conf_files or extra_overlay_confs
or extra_dtc_overlay_files}
3. config files extracted from test scenario's extra_args
4. files listed in test scenario's {extra_conf_files or
extra_overlay_confs or extra_dtc_overlay_files}
Specifying these files in extra_args now triggers a deprecation warning,
as the direct YAML fields are preferred for readability. They will still
function for now but support will be dropped in the future. One
testcase.yaml
(`zephyr/tests/cmake/overlays/var_expansions/testcase.yaml`) is
converted to use the new fields. A follow-up PR will convert the
remaining files to the new format.
Signed-off-by: Tristan Honscheid <honscheid@google.com>
Fix all line-length errors detected by yamllint:
yamllint -f parsable -c .yamllint $( find -regex '.*\.y[a]*ml' ) | \
grep '(line-length)'
Using a limit is set to 100 columns, not touching the commandlines in
GitHub workflows (at least for now).
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Support referencing module directories by name in CONF_FILE,
OVERLAY_CONFIG, and DTC_OVERLAY_FILE so that projects can reference
overlay files in arbitrary modules.
Verified by passing all the following tests:
./scripts/twister -T tests/cmake/overlays/
Fixes#41830
Signed-off-by: Gregory Shue <gregory.shue@legrand.us>
With this commit a dedicated APPLICATION_CONFIG_DIR is added to the
Zephyr build system.
Currently, the APPLICATION_SOURCE_DIR is identical also the base
location of configuration files.
This is very practical for simple samples, but also has it limitations
for more complex setups.
Introducing a dedicated APPLICATION_CONFIG_DIR allows users more
customization options in Zephyr build system.
Especially in terms of custom build configuration files unknown to
Zephyr itself.
For example, instead of all configuration files being located directly
in the application source folder, a project might prefer to organize
their configuration files on a per board basis, for example:
<app>/boards/custom_board_A/prj.conf
<app>/boards/custom_board_A/app.overlay
<app>/boards/custom_board_A/custom_file.mine
<app>/boards/custom_board_B/prj.conf
<app>/boards/custom_board_B/app.overlay
<app>/boards/custom_board_B/custom_file.mine
...
instead of n-files located in the root of the sample.
If the user / sample specifies APPLICATION_CONFIG_DIR, then this folder
will always be used instead of the default configuration folder.
As part of this extension the behaviour of
`-DCONF_FILE=<relative-path>/prj_<build>.conf` and additional Kconfig
fragments automatic sourcing has been aligned with the default behavior
of `prj.conf`.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
