These variables need to be converted to absolute paths internally, but
so far this has only worked when each value consisted of a single path.
Add a common loop to handle lists of paths.
As a bonus, run `string(CONFIGURE)` to expand those variables in the
same way as the regular CONF_FILE and EXTRA_CONF_FILE.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
The recent support for BUILD_ONLY images was implemented by excluding
them from `domains.yaml`, in order to crudely prevent them from being
picked up by `west flash`. Arguably, this is incorrect or unexpected,
because the sysbuild documentation defines a "domain" as:
Every Zephyr CMake build system managed by sysbuild.
Another consequence is that, given a build-only `<image>`, this makes it
impossible to pass `--domain <image>` to `west flash`, `west debug`, and
ironically `west build`.
To fix that, `domains.yaml` should again represent all domains, and the
build-only ones should be indicated in another way. Enter `flash_order`:
a new top-level key in the domains YAML schema. It contains the default
sequence of images used by `west flash`, where the build-only images are
excluded, and the order is influenced by `sysbuild_add_dependencies()`.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Adds support for controlling the MCUboot (and application) signing
key, and allows for generating encrypted updates.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Adjust the order in which image-specific `sysbuild.cmake` files are
iteratively included by sysbuild.
This is motivated by the introduction of `sysbuild_add_dependencies()`.
In the following example:
sysbuild_add_dependencies(CONFIGURE my_sample sample_a sample_b)
the `my_sample` image is expected to be added before this function is
called. Success depends not only on the placement of the call, but on
the order in which new images are added, which itself is influenced by
the order in which `sysbuild.cmake` files are included. This last order
can be tweaked to make the "dependencies" feature more user-friendly.
This is done by rewriting the internal `sysbuild.cmake` processing loop
into a new, general purpose function - `sysbuild_add_subdirectory()` -
which is a wrapper for `add_subdirectory(<source_dir>)` that recursively
includes `sysbuild.cmake` files for all images found in `<source_dir>`.
With the new function, all images that are expected to be found in a
given `<source_dir>` are guaranteed to be added around the same time.
This wasn't the case with the old processing loop, because the image-
specific `sysbuild.cmake` files (where "sub-images" could be defined)
were left to be processed at the very end.
Below is the initial order in which sysbuild will add all images.
Note: the order of Zephyr modules (from 1 to n) is well-defined.
1. Main application (aka DEFAULT_IMAGE)
2. MCUboot (optional)
3. All images added via these directories:
3.1. <module-1>.sysbuild-cmake
3.2. <module-2>.sysbuild-cmake
...
3.n. <module-n>.sysbuild-cmake
4. All images added via these files:
4.1. ${BOARD_DIR}/sysbuild.cmake
4.2. ${APP_DIR}/sysbuild.cmake (aka sub-images of DEFAULT_IMAGE)
These images are intended to be sorted for the users' convenience, from
most to least important in the build system, or least to most dependent
on other images for configuration (potentially).
Finally, the use of `sysbuild_add_subdirectory()` requires updating the
directory structure in sysbuild:
./images
- All images should belong here. The `DEFAULT_IMAGE` should be the
first and only image at the top level, so that it gets added first
and its sub-images get added last.
./images/bootloader
- Moved from ./bootloader.
./images/boards
- Adds images from the board-specific `sysbuild.cmake` file.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
This variable was originally provided for two indended purposes:
* Let users manually add a new image in a desired order in the list.
* Let users set build-only images, which are excluded from the list.
Given the recent additions of the `sysbuild_add_dependencies()` function
and the `BUILD_ONLY` parameter, `IMAGES` should be considered obsolete.
Furthermore, the list of images added to sysbuild should be updated
automatically when calling `ExternalZephyrProject_Add()`. This is now
possible by using a GLOBAL property internal to sysbuild.
With that, the `IMAGES` variable can be removed. Its existing usage for
image ordering is replaced with `sysbuild_add_dependencies()` treewide.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Fixes#53650
The existing solution for image ordering involves the `IMAGES` variable,
which sysbuild originally provided to let users manually add a new image
in a desired order. This isn't very flexible for the following reasons:
* The order in which `IMAGES` is updated across multiple modules and
`sysbuild.cmake` files is not well defined.
* Having a single variable means that the same order is used for both
configuration and flashing. Usually, there is no reason for the
flashing order to be the same as the configuration order.
Introduce the `sysbuild_add_dependencies()` function for more fine-tuned
ordering of images. It makes one image depend on other images in either
configuration or flashing order. Its usage is similar to the standard
CMake function `add_dependencies()`, but with an extra parameter to
distinguish between two types of dependencies:
sysbuild_add_dependencies(CONFIGURE my_sample sample_a sample_b)
sysbuild_add_dependencies(FLASH my_sample sample_c sample_d)
CONFIGURE dependencies determine the order in which sysbuild configures
(runs CMake for) the individual images. This is useful if there is some
information from one application's build which needs to be available to
another application.
FLASH dependencies control the sequence of images used by `west flash`.
This could be used if a specific flashing order is required by an SoC,
a runner, or something else. Note that these dependencies are not valid
for images specified as `BUILD_ONLY`.
The internal `sysbuild_images_order()` function is responsible for
assembling two sorted lists of images based on the added dependencies,
with the help of `topological_sort()`.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Refactor image_config.cmake so that it is no longer sourced
unconditionally for all images. Instead image_config.cmake has been
split into BOOTLOADER_image_default.cmake and MAIN_image_default.cmake
and is set as property on the image.
This means the code in image_config.cmake can be split into dedicated
files which depends on the image type. Furthermore it allows sysbuild
modules to append extra config snippets to process for sysbuild kconfig
overwrite, or even remove the default snippet and have full control.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Export Zephyr image byproducts through `BYPRODUCT_<VAR>` cache
variables.
This allow external tools, such as sysbuild, to read information on
products produced by a Zephyr build from the image CMake cache.
For sysbuild, this means that all byproducts will be added to a phony
build target, which again allow sysbuild itself to depends on target
output and properly describe dependencies between byproducts and their
producing targets.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Add a new parameter to `ExternalZephyrProject_Add()`, which determines
whether a given sysbuild image should only be built and not considered
for flashing and debugging. By adding the following arguments:
BUILD_ONLY TRUE
the image will be marked as build-only and excluded from `domains.yaml`.
For cases where this setting should be controlled by users or individual
samples, Kconfig can be used:
ExternalZephyrProject_Add(
APPLICATION foo
SOURCE_DIR /path/to/foo
BUILD_ONLY ${CONFIG_FOO_IS_BUILD_ONLY}
)
This would be particularly fitting for "general-purpose" images, defined
in-tree or via Zephyr modules (whose inclusion in the multi-image build
should also be Kconfigurable).
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Fixes an issue with relative paths both with and without using
sysbuild where they would not be updated properly or a warning
would previously be emitted.
Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Lately, sysbuild started filtering out variable names matching ^BOARD
during sysbuild cache file generation. As a result, one of the cache
variables that is no longer exported to other domains is BOARD_ROOT,
which breaks the recent support for out-of-tree boards in sysbuild.
Of those variables, the only one which is reasonable to filter out is
BOARD itself, because the purpose of that is to substitute a different
value for the one found in sysbuild's own CMake cache, which has the
board revision stripped out.
Update the relevant if-condition and use a single regex for brevity.
Fixes#59114.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
When calling `sysbuild_get(<out-var> VAR <lookup-var> ...)` user
specifically specify the output variable and in such cases the overwrite
warning should not be printed, because such invocation is similar to a
regular `set(<var> <val>)` CMake call.
Only the invocation where the same variable name is used for lookup and
return variable, then the warning must be printed to avoid unintentional
overwriting of existing variables.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Sysbuild now generates a .config.sysbuild config file which specifies
settings controlled by sysbuild.
Any setting specified in this .config will overrule user provided
setting, and a warning will be raised if the sysbuild controlled value
is different from the value specified by the user.
This has the following benefits:
- Allow sysbuild to control any build setting without adjustments to
the existing Kconfig tree
- Allow sysbuild to adjust settings based on knowledge regarding enabled
images / bootloaders.
- Cleanup CMake code, as settings in sysbuild no longer needs to be
propagated using CMake cache variables.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit improves the BOARD handling for Zephyr images.
Concatenate sysbuild BOARD and BOARD_REVISION to BOARD when creating the
image sysbuild cache file. This ensures that the proper sysbuild
BOARD@REVISION can be correctly inherited.
Current solution creates image specific <image>_BOARD cache variables
whenever a board revision is in use, even if the image is expected to
inherit the BOARD@REVISION value from sysbuild.
This improvement means that only when a dedicated board or
board@revision is specified for an image, then an image sysbuild cache
entry will be created.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Align sysbuild with Zephyr CMake so that sysbuild supports
SB_EXTRA_CONF_FILE. Keep support for the old SB_OVERLAY_CONFIG.
This ensures that sysbuild is consistent with Zephyr CMake configuration
file handling.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This fixes a minor issue in sysbuild, where `-DOVERLAY_CONFIG=...` would
be applied not only to the main application, but also sysbuild itself.
This was incorrect, because sysbuild imports a different Kconfig tree
than normal Zephyr builds, so the same Kconfig fragment file would not
necessarily be valid for both.
This adds a new variable SB_OVERLAY_CONFIG to resolve this ambiguity.
It functions along the lines of SB_CONF_FILE, with both being sysbuild-
specific versions of existing variables.
To ensure that OVERLAY_CONFIG is still passed on to the main application
verbatim, its value is now loaded in `configuration_files.cmake`, rather
than `kconfig.cmake`. This is because the former file is not imported by
sysbuild, and it is where the related variables, such as CONF_FILE and
DTC_OVERLAY_FILE, are loaded as well.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
Adds a new CMake helper function that can be used from sysbuild to
set or update sysbuild CMake cache variables.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Fixes an issue whereby the direct variable was being used instead
of the cache variable when configuring target images.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Provide a uniform way for sysbuild modules to create hooks that are
called at specific time during sysbuild CMake configure time.
A module can create functions following the scheme:
- <module-name>_pre_cmake
- <module-name>_post_cmake
- <module-name>_pre_domains
- <module-name>_post_domains
those functions, if defined, will be called by sysbuild CMake at the
location indicated by the function name.
A new global variable `SYSBUILD_CURRENT_MODULE_NAME` is created, which
a module can use to know it's own name when defining those functions
during sysbuild module CMake inclusion.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes an issue when configuring a project through sysbuild to use
mcuboot and setting the verification to checksum only whereby the
image would be unbootable.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
This commit extends the Zephyr module yaml scheme with additional
entries for sysbuild in the build section.
This allows for Zephyr modules to extend the sysbuild infrastructure
by providing additional CMake and Kconfig files to be included in
sysbuild.
The new settings are:
build:
sysbuild-cmake: <path>
sysbuild-kconfig: <path>/<file>
sysbuild-ext: <true>|<false>
sysbuild-kconfig-ext: <true>|<false>
those settings follow the same pattern as the equivalent Zephyr build
settings but are processed by sysbuild.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Split running CMake from ExternalZephyrProject_add().
This will allow systems to define all Zephyr projects and then at later
stages run the CMake configure stage.
This makes it both cleaner when CMake is invoked as well as prepare for
future work where images could be depending on CMake outcome from other
projects.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Kconfig choices should have setting name so that their default
choice can be adjusted, for example by a board.
It further prevents the `defined with a prompt outside the choice`
warning when trying to re-source a Kconfig tree where choices are
create without a setting name.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Checks if the IMAGES variable has been updated with a duplicate
image name, which would otherwise cause an infinite loop.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #53696
Create a BOARD_REVISION_CONFIG setting to be consistent with the
BOARD_DEFCONFIG setting.
This allows systems which re-uses the Kconfig module to overrule the
file to be used as BOARD_REVISION_CONFIG in same way as is done for
the BOARD_DEFCONFIG file.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #52353
If a CMake variable is available in both local scope and as CMake cache
variable, then the use of `${<var>}` fetches the local scoped variable.
If only the cache variable is set, then things works as expected.
Ensure that the cached variable is always the variable being shared to
images by using `$CACHE{<var>}` instead.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
check_zephyr_package() accepts an one-value arg named "WORKSPACE_DIR".
But it is called with "CURRENT_WORKSPACE_DIR".
Signed-off-by: Ming Shao <smrtos@163.com>
Adds support for all sysbuild targets to have a sysbuild.cmake file
included and processed as part of sysbuild instead of just the main
application.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Load image kconfig setting into image target properties.
This allows sysbuild to evaluate and check image configuration as part
of CMake invocation.
sysbuild_get() is updated to support reading of CMake cache or Kconfig
settings for an image.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit introduces the possibility of a sample to locate
configuration files for extra images that are used when building with
MCUboot.
This allows use-cases where a sample, A, want to include MCUboot but has
adjustments to the default MCUboot configuration.
By adding a Kconfig fragment `<sample>/sysbuild/mcuboot.conf`, then that
fragment will be used together with the default configuration for
MCUboot.
It is also possible to completely replace the MCUboot configuration.
This is done by creating `<sample>/sysbuild/mcuboot/` folder.
This folder will then be used as the `APPLICATION_CONFIG_DIR` when
building MCUboot.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit loads the CMakeCache of Zephyr projects.
This allows sysbuild to fetch information from Zephyr projects into
sysbuild itself.
This commit is a first step in the process of sharing more knowledge
between images and sysbuild, and pave the way for closer sharing of
settings between images.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Enhance sysbuild controlled configurations.
The current scheme of passing settings using `-D` on the CMake
invocation is vulnerable to quoting and lists.
With `zephyr_get()` in place as a uniform way of handling user
controlled settings (CMake cache / environment / CMake local variable)
we have a mechanism in place for a cleaner handling of sysbuild
controlled settings.
This improves the robustness of variable passing and add the same cleans
up and simplifies the logic in sysbuild.
The Kconfig Zephyr CMake module has been updated accordingly so that
CONFIG settings are taken from the sysbuild shadow cache when sysbuild
is used as higher level build system.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit introduces image signing by adding the possibility to
specify algorithm and signing key for sysbuild images.
It introduces Kconfig setting to specify signing algorithm and key file.
It will default the signing key to the default key provided by MCUBoot
if no key has been specified.
When signing is enabling, the signature key will be passed to the
application so the build system can sign the image as post build step.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Support creation of domains.yaml to support
`west <build|flash|debug> --domain` when working with sysbuild multi
image.
Each Zephyr based image is added to list of domain that can be handled
by the Zephyr west extension commands.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit adds CMake and Kconfig files needed to build MCUboot as
an extra image using SYSBuild.
Building an application with MCUBoot using SYSBuild allows users to
build both images using a single build.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This is the initial commit with system build, sysbuild.
Using CMake as infrastructure together with the Zephyr sysbuild allows
us to support a convenient way of building a sample and allow for extra
images to be built as part of a larger system.
It uses Kconfig for configuration of image builds.
This allows for future extension with additional build images.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Modules' names would get concatenated together into single
string, making the message hard to read.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
The CMake function `find_package()` supports the flag QUIET.
QUIET will disable informational printing within CMakes own
find_package function.
To align with CMakes find_package, this commit will honor the QUIET flag
and disable informational printing related to package lookup.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
CMake provides a DEPRECATION level for messages.
This should be used instead of WARNING for deprecated features.
Using DEPRECATION allows users to disable the deprecation warning with
`cmake -Wno-deprecated ...`
or turn deprecation warning into an error using
`cmake -Werror=deprecated`
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Explicitly set the <mode> value to the message printed when including
zephyr modules. The documentation is added to explain why it is
output to stderr, as this has been been subject of multiple PR's
(#31365,#43009).
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Fixes: #43094
This commit introduces a function which updates Zephyr_DIR to point to
the directory of the Zephyr package being loaded.
For Zephyr 3.0 and earlier, the Zephyr_DIR might in some cases be
`Zephyr_DIR-NOTFOUND` or pointing to the Zephyr package including the
boilerplate code instead of the Zephyr package of the included
boilerplate code.
This code ensures that when a package is loaded then Zephyr_DIR will
point correctly.
This ensures that when Zephyr releases <=3.0 is loaded, then Zephyr_DIR
will point correctly, see more in #43094.
Old style Zephyr package will in some cases load boilerplate.cmake
directly so to ensure proper behavior, restrict boilerplate uses of
`find_package(Zephyr)` to not use default search path, but allow only
the current Zephyr.
Of the same reason, only print warning if Zephyr_DIR is not defined as
this indicates old style inclusion.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
CMake find_package() is expected to set the cached variable Zephyr_DIR
with the value of the package included.
Zephyr_DIR in the CMakeCache is used by CMake re-runs for
`find_package(Zephyr)` to directly lookup the package to use.
The Zephyr_DIR is set correctly when a single Zephyr workspace is used
but may in some other cases be set to `Zephyr_DIR=Zephyr_DIR-NOTFOUND`.
This causes CMake to rerun the Zephyr package search mechanism and loop
through potential candidates before loading the correct Zephyr
installation.
After a second run, Zephyr_DIR is n some cases set to
`Zephyr_DIR=<path-to-including-Zephyr>` which might be different from
the Zephyr in use.
The Zephyr_DIR should be pointing to the package defined by ZEPHYR_BASE.
This commit ensures that when ZephyrConfig.cmake package is loaded, then
Zephyr_DIR is set correctly.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit allows to load only subcomponents of the default Zephyr
CMake module, zephyr_default.cmake.
This allows other tools to execute Zephyr CMake build system up to a
specific module and the stop further processing.
This commit is an enabler for future support in twister to process only
devicetree or kconfig, to allow test / sample filtering before
generating a complete build system.
Sub-components can be loaded as:
> find_package(Zephyr COMPONENTS zephyr_default:<sub-component>)
for example:
> find_package(Zephyr COMPONENTS zephyr_default:dts)
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Move the unittest.cmake to the new Zephyr CMake modules dir.
This allows us to have a single Zephyr CMake package and load unittest
module as: 'find_package(Zephyr COMPONENTS unittest)'
This unifies the way Zephyr package is sourced and removes the need for
a dedicated ZephyrUnittest package.
Deprecate the use of: 'find_package(ZephyrUnittest)'
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
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>
Fixes: #35187
This extends the Zephyr package to also honor version when ZEPHYR_BASE
is set in environment.
Specifying `find_package(Zephyr 2.x.y)` without using ZEPHYR_BASE will
lookup a Zephyr in following order:
- Current repo, if that is a Zephyr repo
- Current west workspace
- Exported Zephyr CMake package for freestanding application
and ensure that the chosen Zephyr meets the version criteria.
When setting ZEPHYR_BASE in environment the version check is disabled
and the Zephyr referenced by ZEPHYR_BASE will always be used regardless
of its version.
A user doing `find_package(Zephyr 2.6.0)` and using ZEPHYR_BASE
presumable still want to ensure that the Zephyr referenced by
ZEPHYR_BASE is v2.6.0 or newer.
Also, `west build` with a freestanding application requires ZEPHYR_BASE
in order for west to lookup the `west build` extension command.
This practically means a user cannot both specify a Zephyr version for a
freestanding application and at the same time use `west build` but has
to use plain CMake to ensure correct version check, see #35187.
With this commit, users will have complete Zephyr package version
checking with freestanding applications
find_package(Zephyr 2.6.0 REQUIRED HINTS $ENV{ZEPHYR_BASE})
find_package(Zephyr 2.6.0 EXACT REQUIRED HINTS $ENV{ZEPHYR_BASE})
when also having ZEPHYR_BASE in environment.
This commit has no behavioral change for those patterns:
find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
find_package(Zephyr 2.6.0 REQUIRED HINTS $ENV{ZEPHYR_BASE})
find_package(Zephyr 2.6.0 EXACT REQUIRED HINTS $ENV{ZEPHYR_BASE})
when ZEPHYR_BASE is not in environment.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
