Create a cmake/modules folder containing all Zephyr CMake modules.
All Zephyr cmake files that are included from boilerplate are now
converted into CMake modules which can be individually loaded.
The Zephyr CMake package is updated to support loading of individual
CMake modules using the COMPONENTS argument to `find_package(Zephyr)`.
If the COMPONENTS argument is not specified, the default Zephyr build
system will load.
If COMPONENTS is specified then, only those components and the
dependencies will be loaded.
If a Zephyr CMake module depends on another CMake module which has not
been loaded, it will automatically be loaded.
This allows us to modularize and reuse individual parts of the Zephyr
CMake build system in a more flexible way in future.
Such usage could be:
- Higher livel multi image build system
- Invocation of individual components, for example dts processing by
twister without loading all build code
- Doc build
- Unittesting
With this new CMake package and CMake module scheme then direct
sourcing of boilerplate.cmake has been deprecated.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The user_cache.cmake CMake module remove boilerplate code and place it
inside a dedicated user_cache.cmake CMake module.
The user cache functions has been moved to the new Zephyr CMake module.
This is part of a general CMake overhaul to allow better modularization
and reuse of the Zephyr build system.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
* Use case of interest:
Some platforms are shipping in parallel to the internal FLASH some other
storage / external FLASH (usually a QSPI FLASH) that can be used to
execute (XIP) code from.
The content of this external FLASH can usually be written at flash time
using proper tools (see for example the case of the external FLASH on
the nRF5340DK that can be written at flash time using nrfjprog).
The external FLASH is a nice addition that is extremely useful when a
large application code doesn't entirely fit on the internal FLASH so
that we could want to move part of it in the auxiliary FLASH to XIP the
code from there.
* The problem:
Right now Zephyr doesn't have a formal and generic way to move at build
time part of the code to a different memory region.
* The current status:
Zephyr is indeed shipping a code_relocation feature but that doesn't
entirely match our needs.
When XIP is enabled, the code_relocation feature is used in Zephyr to
move the selected code (that is to copy text section, to initialize data
and zero bss) from FLASH to SRAM at run time and execute code from SRAM.
The relocation is done by a generated snippet of code that is
memcpy()-ing the right content to the destination region also using some
build-time generated portions of linker script to retrieve start and
destination addresses and regions.
* This patch:
This patch is leveraging the code_relocation code and adding a NOCOPY
feature. This feature is using the code_relocation feature to
dynamically build the linker script snippets but entirely skipping the
run-time code relocation so that the code can be XIP-ed from the
destination region.
* Example:
Let's say that we have a big file called `huge_file.c` that we want to
XIP from the external FLASH that is mapped in an EXTFLASH region.
In this case we should enable `CONFIG_XIP` and
`CONFIG_CODE_DATA_RELOCATION` and instruct cmake as follows:
zephyr_code_relocate(src/huge_file.c EXTFLASH_TEXT NOCOPY)
zephyr_code_relocate(src/huge_file.c SRAM_DATA)
this means that:
- The .text section of the `huge_file.c` must reside in the EXTFLASH
memory region and we do not need to copy the section there because we
are going to XIP it (and we assume that the file is going to be placed
in the external FLASH at flash time).
- The .data section of the `huge_file.c` must still reside in the SRAM
memory region.
* TODOs:
It's desirable to have the possibility to relocate libraries and
pre-build files instead of source code files.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Add a new cmake extension function:
dt_comp_path(<var> COMPATIBLE <compatible> [INDEX <idx>])
to get a list of paths for the nodes with the given <compatible>. This
is useful when we have to cycle through several nodes with the same
compatible.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
As part of #40167 is was discovered that devicetree headers are always
generated when CMake re-runs.
This causes all source files that directly or indirectly through
included headers to recompile when CMake re-runs, even if there are no
changes to devicetree.
This commits introduces `zephyr_file_copy(...)` similar to
`file(COPY_FILE ...)` from CMake 3.21.
However, as CMake 3.20 is supported by Zephyr we need a zephyr variant
of this function to allow usage with CMake 3.20.
This ensures that only when there are changes to devicetree headers,
then source files will recompile.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #41435
The use of %<symbol>% works well in Linux and MacOS but when passed
to the linker script generator in Windows the %<symbol>% is processed
by the windows shell causing the value to disappear and thus an empty
value inside the generated ld linker script or scatter file.
This is fixed by using the @ character instead of the % character.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fix the zephyr_linker_dts_memory to lookup the correct property name
when trying to figre the region name.
Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
Remove the `NAME` function argument from `zephyr_linker_dts_memory` as
the name is now automatically derived from the devicetree node.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Update the linker script generator to automatically derive memory
region names from the devicetree node according to the same logic in
`devicetree_regions.h`.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
In the python APIs we use for devicetree, you can generally use an
alias interchangeably with the full path to a node.
For example, dtlib.py says:
[...] both dt.get_node("/foo/bar") and dt.get_node("bar-alias")
will return the 'bar' node below:
/dts-v1/;
/ {
foo {
bar_label: bar {
baz {
};
};
};
aliases {
bar-alias = &bar-label;
};
};
Fetching subnodes via aliases is supported:
dt.get_node("bar-alias/baz") returns the 'baz' node.
Now that we have the necessary helper functions for resolving alias
names, make the CMake APIs to devicetree behave the same way. This
improves consistency between the two sets of devicetree helpers used
by the build system, making them both match the general devicetree
practice that an alias is as good as a path. This is good for
consistency.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is a helper function for looking up the path to a devicetree
alias. It is analogous to dt_chosen(). It has to exist as a separate
function from dt_prop() for similar reasons that dt_chosen() does:
the edtlib APIs for interacting with /aliases are special-cased in the
same way they are for /chosen.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Fixes an issue on SOF-supported boards where the build system
incorrectly believed that the rimage target was changing when rerunning
CMake, even though the user did not change any configuration. This issue
was introduced in commit 525fa76f4d.
Create initial build dir:
$ west build --board intel_adsp_cavs18 samples/subsys/audio/sof
Re-run CMake with no arguments in that build dir:
$ cd build
$ cmake .
CMake Warning at /home/mhelm/zephyrproject/zephyr/cmake/extensions.cmake:2403 (message):
The build directory must be cleaned pristinely when changing rimage target,
Current value="", Ignored value="cnl"
Call Stack (most recent call first):
/home/mhelm/zephyrproject/zephyr/cmake/extensions.cmake:829 (zephyr_check_cache)
/home/mhelm/zephyrproject/zephyr/boards/xtensa/intel_adsp_cavs18/board.cmake:6 (board_set_rimage_target)
/home/mhelm/zephyrproject/zephyr/cmake/app/boilerplate.cmake:635 (include)
/home/mhelm/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
/home/mhelm/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
CMakeLists.txt:5 (find_package)
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
Removes hardcoded logic in the west signing script that translates
Zephyr board names to rimage target names. Instead, use a cached CMake
variable set at the board level to define its respective rimage target
name. This eliminates the need to modify the west signing script when
new SOF-supported boards are introduced to Zephyr.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
To prepare for linker script creation with flexible number of linker
passes depending on system configuration then the Zephyr CMake linker
script generator has been updated to use pass names instead of pass
numbers.
This allows greater flexibility as a section can now be active based on
the settings on the pass and not the linking pass index number.
As part of this, the `PASS` processing in `linker_script_common.cmake`
has been adjusted so that it properly handles when a linking pass is
handling multiple settings, such as both `LINKER_APP_SMEM_UNALIGNED`
and `DEVICE_HANDLES_PASS1` in same linking pass.
As the number of linking passes are more flexible, then the PASS
argument in `zephyr_linker_section()` and
`zephyr_linker_section_configure()` has been updated to also support
a `NOT <name>` argument, for example: `PASS NOT LINKER_ZEPHYR_FINAL`.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit creates a new `zephyr_build_string()` function.
`zephyr_build_string()` provides a common way of constructing a build
string based on board name, board revision, and build type.
Having this as a function facilitate creation of names in a common way
and thus helps to ensure naming consistency, especially if newer info
is later embedded into the build string.
Initially the build string will be used to lookup configuration
fragments and devicetree overlay files.
This function is used by `zephyr_file(CONF_FILES ...)`.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The root cause of #38591 was region symbols being placed before the
section description for data region.
Some region start symbols are placed before section description, other
region start symbols are placed inside the first section in the region
and thus identical to the sections own first symbol.
To support both schemes with the linker generator, a new
`SYMBOL SECTION` argument has been added to the zephyr_linker_group()
function.
The ld_script.cmake linker script generator has been updated to support
the new argument so that generated ld linker script has identical
behavior to the templated ld linker scripts.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #38761
The introduction of zephyr_library_property in #38347 contained a
stray function call `target_compile_definitions()` resulting in the
library property name and value to also be added compile definitions to
the Zephyr library.
The Zephyr library property is an internal property and is not supposed
to be added as compile definitions, and thus this call is removed with
this commit.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #37637
toolchain_parse_make_rule() parses depfiles and converted `\\` to the
CMake list separator `;`.
However, gcc -M might create depfiles with windows path separator `\`
causing this conversion to fail, as a path like:
c:\...\zephyr\samples\drivers\led_ws2812\nrf52-bindings.h
resulting in a file list as:
c:;...;zephyr;samples;drivers;led_ws2812;nrf52-bindings.h
which results in a CMake configure dependency to be added to `C:`.
As C: is always newer than the build.ninja file, this resulted in
continues CMake re-invocation.
As a small side-note, the `\` in file name did only occur in situations
where a relative past had been used elsewhere in the build system, such
as here:
https://github.com/zephyrproject-rtos/zephyr/blob/\
c3050a5aab1e86d02642eb4c6a027419e6a3a096/samples/drivers/led_ws2812/\
boards/nrf52dk_nrf52832.overlay#L9
To ensure proper handling of files, then all files are converted to
CMake paths, that is with forward slashes: `/`
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
If the BOARD_RUNNER_ARGS_${runner_id} variable contains anything, add
it to the global property of the same name with all the final runner
args from board_runner_args() and friends.
This allows use cases like this:
west build ... -- -DBOARD_RUNNER_ARGS_jlink="--some-jlink-arg"
The ${runner_id} part is the runner's name converted to a C
identifier, i.e. with special characters changed to underscores.
So e.g. the 'dfu-util' runner would use BOARD_RUNNER_ARGS_dfu_util.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This introduces a dedicated zephyr_library_property() function which
provides a common way to set Zephyr build system known properties on
Zephyr libraries.
As a first common property is the `ALLOW_EMPTY` property which allows
to create a `zephyr_library()` without putting any content inside of it.
In general libraries should not be created unless there are files to
places inside of it, however in some cases there are so many
`zephyr_library_sources_ifdef(<setting> <file.c>)`
where testing each setting before creating the library may not be
desired.
This commit allows the following construct in those cases:
```
zephyr_library()
zephyr_library_property(ALLOW_EMPTY TRUE)
zephyr_library_sources_ifdef(CONFIG_SETTING_1 file_1.c)
zephyr_library_sources_ifdef(CONFIG_SETTING_2 file_2.c)
...
zephyr_library_sources_ifdef(CONFIG_SETTING_n file_n.c)
```
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit introduces zephyr_linker_dts CMake functions for creation of
linker scripts based on devicetree nodes.
The linker devicetree functions supports the following features:
- Configuration of memory sections based on devicetree nodes
Overview of functions introduced with this commit:
- zephyr_linker_dts_memory
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit introduces zephyr_linker CMake functions for creation of
linker scripts.
The linker functions supports the following features:
- Configuration of memory sections
- Configuration of memory groups
- Creation of output sections
- Configuration of input section the should go into output section and
how those should be treated, such as sorting, keep, priority.
- Defining linker symbols
- Specifying Kernel VMA to support virtual linking on x86
Overview of functions and macros introduce with this commit:
- pow2round
- zephyr_linker
- zephyr_linker_memory
- zephyr_linker_memory_ifdef
- zephyr_linker_group
- zephyr_linker_section
- zephyr_linker_section_ifdef
- zephyr_iterable_section
- zephyr_linker_section_obj_level
- zephyr_linker_section_configure
- zephyr_linker_symbol
- zephyr_linker_property_append
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit moves the '_ifndef' functions that are implemented in the
"3.1. *_ifdef" section to the "3.2. *_ifndef" section.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit introduces devicetree API in CMake so that devicetree
properties and register block can be used in the CMake build system.
The script scripts/dts/gen_dts_cmake.py processes the edt.pickle and
generates a corresponding devicetree property map in a devicetree_target
that is then used in CMake.
The following devicetree API has been made available in Zephyr CMake:
- dt_nodelabel(<var> NODELABEL <label>)
- dt_node_exists(<var> PATH <path>)
- dt_node_has_status(<var> PATH <path> STATUS <status>)
- dt_prop(<var> PATH <path> PROPERTY <prop>)
- dt_prop(<var> PATH <path> INDEX <idx> PROPERTY <prop>)
- dt_num_regs(<var> PATH <path>)
- dt_reg_addr(<var> PATH <path> [INDEX <idx>])
- dt_reg_size(<var> PATH <path> [INDEX <idx>])
- dt_has_chosen(<var> PROPERTY <prop>)
- dt_chosen(<var> PROPERTY <prop>)
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The zephyr_library_* variant is missing the ability to
include directories based on kconfig. So add the function.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Current location options for linker source files includes init and
noinit ram data, but only a noinit ram section. This makes it impossible
for application code to define an initialized RAM output section,
such as with the Z_ITERABLE_SECTION_RAM() helpers.
Adding a DATA_SECTIONS linker source option for this use case.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Add some more example to the description of zephyr_library_amend().
This should help users to get input of the extra possibilities that this
function provides.
See: #35770
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
With this change, we can put contents into rom_start section
by calling zephyr_linker_sources(ROM_START ...)
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Co-authored-by: Torsten Tejlmand Rasmussen
Change-Id: If1169423b013d3e4df52d91cdb2fbdddc3bace7b
Fixes: #19582
When `find_package(Zephyr)` completes then all boilerplate code has been
processed and all Zephyr libraries has been placed inside the
whole archive flags.
Also all libs dependencies has been processed.
This is indicated by the presence of the zephyr_prebuilt target.
Thus, warn the user if `zephyr_library()` / `zephyr_library_named()`
is called in app-mode.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
There is a comment which needed to be rephrased for inclusive
language. This commit replaces it with the recommended
replacement.
Signed-off-by: Jennifer Williams <jennifer.m.williams@intel.com>
With the introduction of #32556 changing the BOARD now prints a warning.
Zephyr provides `zephyr_file()` to look up overlays and Kconfig
fragments for a specified board, and it used to be possible and safe to
do:
```
function(my_func)
set(BOARD <local_scope_board>)
zephyr_file(CONF_FILES ...)
endfunction(my_func)
```
As the BOARD inside `my_func` is locally scoped, this is safe to do.
But with introduction of #32556 a warning is now printed when running
CMake.
Therefore `zephyr_file` has been extended to allow for optional BOARD
and BOARD_REVISION arguments.
If BOARD is not given as argument the current BOARD in the build system
will be used.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Watching of specific Zephyr CMake build variables ensure users cannot
accidentally set important variables, such as BOARD, SHIELD, CONF_FILES
late in the build process.
This was also added to zephyr_check_cache() function.
However, the BOARD provided by the user may look as `<board>@<revision>`
and will be kept in the cache in that form.
However, the BOARD value from cache is spit into internal build
variables as: BOARD=<board> and BOARD_REVISION=<revision>.
However, this is done after `zephyr_check_cache()` which then triggers
the variable watch to trigger, and printing a warning when using board
revisions.
Therefore WATCH is now optional for `zephyr_check_cache()` and watch for
BOARD variable will be enabled when boilerplate has completed all board
handling.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
To remove the need of empty config files, the `board_check_revision()`
now accepts a list of valid revisions.
As example:
```
board_check_revision(
FORMAT MAJOR.MINOR.PATCH
VALID_REVISIONS 0.1.0 0.5.0 0.10.0
)
```
The code is still compatible with the `<board>_<revision>.conf` changes
so that if different revisions of a board has Kconfig differences, then
there is no need to also specify the list of valid revisions.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Several variables must be set by the time boilerplate.cmake is run.
This includes BOARD, SHIELD, CONF_FILE, and DTC_OVERLAY_FILE.
It's not always clear to users that this is the case, and we sometimes
see attempts to modify these variables in app CMakeLists.txt files
after find_package(Zephyr ...) lines, where they will have no effect.
This causes confusion.
Add a new extension function, zephyr_boilerplate_watch(), which traps
attempts to set these variables and prints a noisy warning. Use it
from boilerplate.cmake on the variables mentioned above.
This will hopefully make it clearer at build time why the changes are
being ignored.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Fixes: #23449
This commit adds additional OUTPUT and BYPRODUCTS to custom command
and targets in the Zephyr build system.
This ensures that files produced during the build will be removed again
when invoking ninja clean / make clean.
The generated syscalls headers include folder is added to the syscall
target using ADDITIONAL_CLEAN_FILES property.
However, this property is new in CMake 3.15, so will not work when using
older CMake with ninja.
For CMake versions <=3.15 the ADDITIONAL_MAKE_CLEAN_FILES property is
used. However, this only supports Makefile generator.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The introduction of Zephyr module glue code in the Zephyr repository
introduces a Kconfig variable in the form of:
`config ZEPHYR_<MODULE_NAME>_MODULE`.
All Kconfig variables go into `autoconf.h`, therefore it is necessary
to sanitize the Kconfig variable, so that it does not contain special
characters. To ensure consistent variable name, then the module name
will be sanitized in all variable use in both Kconfig and CMake.
The sanitization is done be replacing all special characters with an
underscore, `_`.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Remove the boards and shields lists from the 'usage' target output.
That might have been readable at some point long ago in Zephyr's
history, when only a few boards were available, but right now it's
obscuring the high level targets we really want 'usage' to print.
Instead, add 'boards' and 'shields' targets which the user can run to
get those lists, and reference them from the 'usage' output. This
makes 'usage' squintable again. We use the new list_boards.py script
from the 'boards' target.
Reference the 'help' target from 'usage' as well, and drop the
recommendation that people run '--target help' from the 'west build
--help' output for the 'west build --target' option. The canonical
place to look is 'usage' now.
Use the new list_boards.py code from 'west boards' as well, which
allows us to add the board's directory as a format string key, in
addition to its name and architecture.
Keep west-completion.bash up to date. While doing that, I noticed that
a bunch of references to this file refer to a stale location, so fix
those too.
Finally, the 'usage' output is what we print for a failed board or
shield lookup, so that needs to be updated also. Handle that by
invoking boards.cmake and a new shields.cmake in CMake script mode to
print the relevant output.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This commit contains some additional review comments that was posted
after board revision PR #29990 was merged.
The follow-up changes are:
- Fixed typo: REVIVISION --> REVISION
- Renaming leftover in print message:
zephyr_check_board_revision --> board_check_revision
- Fixed regex, to allow revision 10, 20, 30, 40, etc.
- digits --> number in comment
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit introduces support for versioning of boards.
The existing board handling is limited in such a way that it is not
possible to support a specific board in multiple variants.
This commit introduces versioning of board revisions so that it is
possible to support minor variations to a board without having to
defining a completely new board.
This can be done by adding a revision.cmake file in the board folder:
boards/<arch>/<board-dir>/revision.cmake
Depending on the revision format chosen, additional configuration files
for each revision available must also be added, those have the form:
boards/<arch>/<board-dir>/<board>_<revision>.conf
Examples:
boards/<arch>/<board-dir>/<board>_defconfig: Common board settings
Revision format: MAJOR.MINOR.PATCH
boards/<arch>/<board-dir>/<board>_0_5_0.conf: Revision 0.5.0
boards/<arch>/<board-dir>/<board>_1_0_0.conf: Revision 1.0.0
boards/<arch>/<board-dir>/<board>_1_5_0.conf: Revision 1.5.0
Revision format: LETTER
boards/<arch>/<board-dir>/<board>_A.conf: Revision A
boards/<arch>/<board-dir>/<board>_B.conf: Revision B
The `board_check_revision` function is available in `extensions.cmake`
to facilitate board revision handling in `revision.cmake`.
User select the board revision using: `-DBOARD=<board>@<revision>`, as
example `-DBOARD=plank@0.5.0`.
If a shield, test, sample, or application needs to specify DTS overlay
or Kconfig fragments, this can be done by adding revision specific
configuration files in the sample/test/shield folder, like this:
<shield/sample-path>/boards/<board>.conf
<shield/sample-path>/boards/<board>_<revision>.conf
or if there is there is only a need for adjusting on a given board
revision:
<shield/sample-path>/boards/<board>_<revision>.conf
Similar for DTS overlay files:
<shield-path>/boards/<board>.overlay
<shield-path>/boards/<board>_<revision>.overlay
or:
<shield-path>/boards/<board>_<revision>.conf
For test/samples/apps:
<sample-path>/<board>.overlay
<sample-path>/<board>_<revision>.overlay
or:
<sample-path>/<board>_<revision>.overlay
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This commit extends zephyr_file(<mode>) to support `CONF_FILES` which
allows for finding and appending Zephyr Kconfig fragments and DTS
overlays.
Introducing mode:CONF_FILES allows have a uniform way of looking up
<board>.conf and <board>.overlay, and ensure that extending such
functionality keeps identical behaviour in shields, tests, and samples.
Using zephyr_file(CONF_FILES) a lot of duplicated code can be removed.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Cleanup board and shield cmake code so that code duplication is reduced.
Before this commit, the code for verifying if BOARD or SHIELD user input
had changed was almost identical.
The common code has been made into a Zephyr extension function so that
all part of Zephyr build system can have a uniform way of checking if
sticky arguments has changed, and print user warning in a uniform way.
This also fixes an undiscovered flaw, where changing a shield is not
possible if a shield was defined at first CMake invocation, but in case
no shield had been specified at all, then build system would wrongly
allow specifying and changing shields, for example doing:
cmake -DBOARD=nrf52840dk_nrf52840 -DSHIELD=sparkfun_sara_r4 <sample>
cmake -DSHIELD=wnc_m14a2a
results correctly in:
> CMake Warning at zephyr/cmake/app/boilerplate.cmake:287 (message):
> The build directory must be cleaned pristinely when changing shields
and correctly keep existing SHIELD settings.
but doing:
cmake -DBOARD=nrf52840dk_nrf52840 <sample>
cmake -DSHIELD=sparkfun_sara_r4
cmake -DSHIELD=wnc_m14a2a
would not result in any warning, because `CACHED_SHIELD` was not
correctly checked in this case.
Changing shield is not a supported feature as it have unknown behavior.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
