Commit graph

9 commits

Author SHA1 Message Date
Torsten Rasmussen ef3c5e5516 cmake: west: invoke west using same python as rest of build system
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>
2020-07-08 23:23:04 -04:00
Torsten Rasmussen 39cd4c8f52 cmake: propagating zephyr base to west
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>
2020-03-27 16:23:46 +01:00
Sigvart M. Hovland 06365a5ed1 cmake: zephyr_modules: Add west executable argument
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>
2019-05-03 14:23:09 -04:00
Anas Nashif 3ae52624ff license: cleanup: add SPDX Apache-2.0 license identifier
Update the files which contain no license information with the
'Apache-2.0' SPDX license identifier.  Many source files in the tree are
missing licensing information, which makes it harder for compliance
tools to determine the correct license.

By default all files without license information are under the default
license of Zephyr, which is Apache version 2.

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-04-07 08:45:22 -04:00
Marc Herbert c240b69956 zephyr_module.cmake: restore ability to build without modules
Kconfig.modules used to be an empty file when no modules. PR #14667 /
commit bd7569f272 "cmake: Extracted Zephyr module processing into
python script" unintentionally changed that to no Kconfig.modules file
at all when no west and no modules. kconfig.py doesn't like that and
crashes. Restore the empty file.

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-04-01 03:10:26 +08:00
Torsten Rasmussen bd7569f272 cmake: Extracted Zephyr module processing into python script
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>
2019-03-29 23:10:59 -04:00
Sebastian Bøe 7061c035cd kconfig: Move Kconfig.modules to the root build directory
Currently, the Kconfig.modules file is placed in the build directory
relative to the CMake "project". But technically, the file is not
project-specific, but global, or build-directory specific.

So we move it up one level to the CMAKE_BINARY_DIR instead. Currently,
there is only one project, so this change has no effect, but this
enables us to have multiple projects in the future, which again
enables multi-image builds.

Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2019-03-28 09:23:02 -04:00
Torsten Rasmussen d042d628b6 cmake: west: Allow mono-repo to build when west is installed
If one invokes cmake with west in the PATH but not inside a west
installation (i.e. in a monorepo setup), west will try to list the
zephyr modules issuing an error message.

Test if west list succeeds before using result for module testing.

Fixes #14177

Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2019-03-11 20:38:03 -07:00
Torsten Rasmussen 7e9d1bdda4 CMake/Kconfig: CMake and Kconfig build integration
This commit allows for Zephyr modules to be natively integrated into
the build system with CMakeLists.txt and Kconfig files.

The sourcing of module files are done in following order:
- If <module>/zephyr/module.yml exists, use cmake and kconfig settings
  for sourcing of additional file
- Else if <module>/zephyr/CMakeLists.txt exists, source this file into
  CMake build tree and add <module>/zephyr/Kconfig as osource

If none of the above files are present, the project is considered to
not be a Zephyr module

Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2019-02-08 22:47:02 -05:00