Twister should be partially usable even without West installed, however,
Twister unconditionally tries to import it when initializing to check
for west projects and crashes if it is not there.
This PR changes the behavior to return None if the west imports failed,
which appears to be more in line with what was intended. This allows
Twister to proceed and successfully run tests in a non-west environment.
There is no impact on environments that do have west installed.
Fixes#45355
Signed-off-by: Tristan Honscheid <honscheid@google.com>
Although CMake scripts already support duplicated module
names, if two modules with the same name provide different
Kconfig files, then both files will be loaded leading to
potential conflicts.
Modify zephyr_module.py to enforce that all modules are
uniquely named so that it is possbile to override some of
the built-in modules using ZEPHYR_EXTRA_MODULES variable.
Signed-off-by: Damian Krolik <damian.krolik@nordicsemi.no>
The PR #39382 raised a discussion on build reproducibility and knowledge
of west projects being out of sync with the west manifest.
Similar to how `git submodules` will report the working tree dirty if
any of the submodules HEAD points to a SHA different than the one
recorded in the super project.
Based on this discussion this commit extends the Zephyr and manifest
repo (when `west` is used) revisions to include the concatenated states
of the workspace.
The workspace states are:
> dirty: false / true
> extra: false / true
> off: false / true
the final revision will become: <SHA>-<state1>-<state2>-<state3>
For example:
> zephyr:
> path: /.../zephyr
> revision: <SHA>-dirty-extra-off
or
> zephyr:
> path: /.../zephyr
> revision: <SHA>-extra
The `BUILD_OUTPUT_META_STATE_PROPAGATE` Kconfig setting is introduced
to provide user control of this behavior.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The PR #39382 raised a discussion on build reproducibility and knowledge
of west projects being out of sync with the west manifest.
Similar to how `git submodules` will report the working tree dirty if
any of the submodules HEAD points to a SHA different than the one
recorded in the super project.
Based on this discussion this commit extends the Zephyr build meta file
with overall workspace status included in the meta file.
It adds the following meta info to the build meta file:
> workspace:
> dirty: false / true
> extra: false / true
> off: false / true
A project using west and having an extra Zephyr module loaded not
controlled using git and a west project at a SHA different than the
SHA referenced by the manifest can look like:
zephyr:
path: /.../zephyr
revision: 863600cd0e
modules:
- name: mcuboot
path: /.../bootloader/mcuboot
revision: c61538748ead773ea75a551a7beee299228bdcaf
- name: local_module
path: /.../local_module
revision: null
west:
manifest: /.../zephyr/west.yml
projects:
- path: /.../zephyr
revision: 863600cd0e
- path: /.../bootloader/mcuboot
revision: c61538748ead773ea75a551a7beee299228bdcaf-off
- path: /.../tools/net-tools
revision: f49bd1354616fae4093bf36e5eaee43c51a55127
workspace:
dirty: false
extra: true
'off': true
And without west:
zephyr:
path: /.../zephyr
revision: 863600cd0e
modules:
- name: hal_nordic
path: /.../modules/hal/nordic
revision: a6e5299041f152da5ae0ab17b2e44e088bb96d6d
- name: local_module
path: /.../local_module
revision: null
workspace:
dirty: false
extra: true
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
kconfiglib doesn't render backslashes in menu strings, and the prompts
in the module menu will be unintelligible on Windows. Print these
menus as posix paths on Windows as well, so they don't look broken in
menuconfig.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
This commit is motivated by the west discussion in:
https://github.com/zephyrproject-rtos/west/issues/548
The commit provides the ability to generate a build meta info file
containing lists of:
- Zephyr: path and revision
- Zephyr modules: name, path, and revision
- West: manifest path
path and revision for each project
For Zephyr or Zephyr modules the revision will be `null` if it is not
under git version control.
If Zephyr, a modules, or a project has uncommitted changes, the revision
will be marked dirty.
If west is not installed or used for the build process, the
west-projects list will be empty.
If a project is both a Zephyr module and a west project it will show up
in both lists.
Similar to Zephyr, which is independently referred as the Zephyr in use
but also listed as west project when west is used.
This is important in case ZEPHYR_BASE was manually set and pointing to
a different Zephyr repository.
The build meta file is not created per default but can be enabled with
the BUILD_OUTPUT_META Kconfig setting.
A project using west and having an extra Zephyr module loaded not
controlled using git can look like:
zephyr:
path: /.../zephyr
revision: 863600cd0e3c0a271e86629c5089821e5e4380cc-dirty
modules:
- name: mcuboot
path: /.../bootloader/mcuboot
revision: c61538748ead773ea75a551a7beee299228bdcaf
- name: local_module
path: /.../local_module
revision: null
west:
manifest: /.../zephyr/west.yml
projects:
- path: /.../zephyr
revision: 863600cd0e3c0a271e86629c5089821e5e4380cc-dirty
- path: /.../bootloader/mcuboot
revision: c61538748ead773ea75a551a7beee299228bdcaf
- path: /.../tools/net-tools
revision: f49bd1354616fae4093bf36e5eaee43c51a55127
And without west:
zephyr:
path: /.../zephyr
revision: 863600cd0e3c0a271e86629c5089821e5e4380cc-dirty
modules:
- name: hal_nordic
path: /.../modules/hal/nordic
revision: a6e5299041f152da5ae0ab17b2e44e088bb96d6d
west: null
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
I saw a user wondering what this is for and and where it comes from.
Provide a comment header with some explanation and a pointer to where
to find out more.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add parse_modules() function, which will offload most of the work in
main() and additionally allow external Python code to use that function.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
West has introduced support for group tags in:
https://github.com/zephyrproject-rtos/west/pull/454
This means that manifest files might start containing groups.
Zephyr itself only requires west>=0.7.2 where groups are not supported
but other Zephyr based projects might start using the group feature.
When using a west version with group support, then only active projects
will be processed as Zephyr modules.
West versions without group support will consider all projects active.
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>
The folder name of a Zephyr module is also used as its module name
when integrating it into the build system.
This means that a Zephyr module, BAR, located in:
<workspace>/modules/foo
|--- zephyr
|--- CMakeLists.txt
|--- Kconfig
will be referred to as FOO in the build system, that is:
ZEPHYR_FOO_MODULE_DIR==<workspace>/modules/foo
ZEPHYR_FOO_CMAKE_DIR==<workspace>/modules/foo/zephyr
The `name` field allows the module to specify its module name,
independent of its location like:
<workspace>/modules/foo/zephyr/module.yml
```
name: bar
build:
cmake: zephyr
```
will instead be referred to as BAR in the build system, that is:
ZEPHYR_BAR_MODULE_DIR==<workspace>/modules/foo
ZEPHYR_BAR_CMAKE_DIR==<workspace>/modules/foo/zephyr
This allows for greater flexibility of relocating Zephyr modules in
other folders and at the same time be guaranteed that other modules
depending on `ZEPHYR_BAR_MODULE_DIR` is still working.
If `name` field is not specified in `module.yml`, then the existing
behavior of using the folder name will be used.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit introduces MODULE_EXT_ROOT which allows CMake and Kconfig
glue code to be placed outside of the Zephyr module repository.
This allows for placing glue code in Zephyr, but also allows users to
specify custom MODULE_EXT_ROOTs for glue code using either
`-DMODULE_EXT_ROOT` or `zephyr/module.yml` with
`build:settings:module_ext_root` settings.
MODULE_EXT_ROOT' is a list of directories, similar to other roots such
as BOARD_ROOT, DTS_ROOT, etc.
The Zephyr repo folder ${ZEPHYR_BASE} is always to the MODULE_EXT_ROOT
list as lowest priority.
For each MODULE_EXT_ROOT, the file
`<module_ext_root>/modules/modules.cmake` will be processed.
In Zephyr repo, the folder `modules/<module>/` contains CMakeLists.txt
and Kconfig glue code for the Zephyr module.
A Zephyr module can specify that CMakeLists.txt and Kconfig glue code is
placed in an external module root by specifying:
```
build:
cmake-ext: True
kconfig-ext: True
```
It is still possible to place the CMakeLists.txt and Kconfig files
directly in the Zephyr module using the existing:
```
build:
cmake: <path>
kconfig: <file>
```.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #29235
This commit ensures that roots are being converted to posix paths.
This fixes the issue where windows style path (containing `\`) would
result in DTS dependency file to contain mixed style path separator and
thus causing Ninja to re-invoke CMake in an endless loop.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit improves Zephyr modules support in CMake.
All Zephyr modules will now have a corresponding
`ZEPHYR_${module_name}_MODULE_DIR` set, regardless of whether they
define a cmake folder in module.yml.
This results in:
`ZEPHYR_${module_name}_MODULE_DIR` defined for all modules and refers to
the root of the modle.
`ZEPHYR_${module_name}_CMAKE_DIR` defined for modules that specifies
cmake in module.yml, or is having both a CMakeLists.txt and Kconfig file
in the zephyr folder.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit has no functional changes but is simply a cleanup so that
flake8 will pass without warnings.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #25215
This commit introduces the possibility of defining ROOTs in a Zephyr
module and have it automatically appended to list of other ROOTs.
Supported with this commit:
- BOARD_ROOT
- SOC_ROOT
- DTS_ROOT
- ARCH_ROOT
In order to support this in Zephyr module files, the detection of west
has been moved to dedicated west.cmake file and included immediately
after python.cmake.
Also the inclusion of zephyr_modules.cmake has moved before first use
of BOARD_ROOT.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The projects variable needs to be initialized with the list of modules
provided via cmd-line arguments.
This is a regression introduced by
ef3c5e5516.
Fixes#26948.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
When running CMake, then Python3 will be used.
This is detected through FindPython3, with a preference for using the
python or python3 in path, if any of those matches the required Python
minimal version in Zephyr.
It is also possible for users to specify a different Python, as example
by using:
`cmake -DPYTHON_PREFER=/usr/bin/python3.x`
However, when running `west` as native command, then west will be
invoked on linux based on the python defined in:
`west` launcher, which could be: `#!/usr/bin/python3.y`
Thus there could be mismatch in Pythons used for `west` and the python
used for other scripts.
This is even worse on windows, where a user might experience:
```
>.\opt\bin\Scripts\west.exe --version
Traceback (most recent call last):
File "C:\Python37\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
...
File "C:\Python37\lib\socket.py", line 49, in <module>
import _socket
ImportError: Module use of python38.dll conflicts with this version of
Python.
```
when testing out a newer Python, but the python in path is still a 3.7.
By importing `west` into zephyr_module.py and by using, as example
`python -c "from west.util import west_topdir; print(topdir())"`
we ensure the same python is used in all python scripts.
Also it allows the user to control the python to use for west.
It also ensures that the west version being tested, is also the version
being used, where old code would test the version imported by python,
but using the west in path (which could be a different version)
If the west version installed in the current Python, and west invocation
is using a different Python interpreter, then an additional help text
is printed, to easier assist users with debugging.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit introduces the possibility of adding dependencies between
Zephyr modules to ensure that a Zephyr module on which other modules
depends is processed first.
The dependency chain is ordered using a topological sort.
This allows to add dependencies to a zephyr/module.yml as:
build:
cmake: .
depends:
- fatfs
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
West utilizes Zephyr base when invoked out-of-tree in order to determine
west topdir.
This commit ensures that zephyr base when invoking west from CMake is
set to current zephyr base.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The west command line output is not stable and has changed for 0.7.
Match it in zephyr_module.py's check for whether we are in a
workspace.
The real fix is to start using 'west topdir' whenever the west version
is at least 0.7.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add error checking in zephyr_module.py so that if the user manually
specifies ZEPHYR_EXTRA_MODULES and the list contains something that
isn't in fact a valid module, we scream and die.
This should help with diagnosing module errors.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
It is supported to have a zephyr module that does not have a
module.yml, but zephyr_module.py does not support it and will drop
such modules.
To fix this we add support in zephyr_module.py.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Generate options for sanitycheck to run tests and samples in modules.
Use the --sanitycheck-out <file> to generate a file that can be supplied
to sanitycheck on the commandline which will add additional testroots
and boards if the module does contain out of tree boards.
the module.yaml file now accepts the following:
samples:
- path/to/samples
tests:
- path/to/tests
boards:
- path/to/boards
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Now using only Path and PurePath in zephyr_modules.py to handle module
processing.
This make the code cleaner as well as remove an issue where a module
name would become an empty string when module path contained trailing
path separators.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit fixes an issue in windows where zephyr_modules.txt contains
a \ as path separator.
This causes issues later when using the path generated by
zephyr_module.txt are used as variables in CMake on windows.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Promote a handy and often-overlooked sys.exit() feature: Passing it a
string (or any other non-int object) prints it to stderr and exits with
status 1.
See the documentation at
https://docs.python.org/3/library/sys.html#sys.exit.
This indirectly prints some errors to stderr that previously went to
stdout.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Zephyr verifies if it is built from a west-initialized directory.
The message changed in west@c08061cef1c7b0e19a58a82db731098e2f4bba4a.
Closes#18034.
Signed-off-by: Piotr Zierhoffer <pzierhoffer@antmicro.com>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
In order to make sure that the build works in folders that require a UTF
encoding, make sure that both CMake and the various Python scripts that
interact with each other on files use the same encoding, in this case
UTF-8.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
On some systems where you don't have access to `PATH` and you can't
set the `ENV{PATH}` variable. You need to be able to pass the path
to the west executable down to the python script so it is better
for it to be set explicitly than assuming that it exsists as a
part of the PATH/executables in the shell being called.
Signed-off-by: Sigvart M. Hovland <sigvart.hovland@nordicsemi.no>
Fixes: #15664
This commit improve error messaging in case `west` list fails.
Previously any error messages and stack trace reported by `west` will
was thrown away by zephyr_module.py.
Now the error, as well as any stack traces, printed by `west` will be
re-printed to the user.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #15289
Kconfig requires posix style path when sourcing other files.
As abspath in python will use native host style, i.e. backslash '\' in
windows this will cause invalid paths in Kconfig generated file and
thus the file will never be loaded.
This commit uses PurePath to convert the path to posix style, ensuring
Kconfig can load the modules.
Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
Due to the fact that CMake only supports greedy regexes,
the ':' in a Windows path ('C:\...') was being matched leading
to an invalid split of the line. Quote both the name and the path
to avoid this issue.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Fixes: #14513
This commit move the functionality of extracting zephyr modules into
generated CMake and Kconfig include files from CMake into python.
This allows other tools, especially CI to re-use the zephyr module
functionality.
Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
