A variable set by the user with `-DVAR=<val>` will be given the type
UNINITIALIZED.
This results in the variable not being read into the cmake_cache.
Support reading of CMake cache variables of type UNINITIALIZED.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Handle a semantic versioning case used by Kitware that is not
supported by the packaging module we're using for version comparisons.
Signed-off-by: Martí Bolívar <marti.bolivar@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>
The variables with the STATIC type aren't read.
The commit 877fc59e30 introduce the read of CMAKE_PROJECT_NAME
which could be defined in CMakeCache.txt file like that:
CMAKE_PROJECT_NAME:STATIC=MyProject
If STATIC type is not managed, the CMAKE_PROJECT_NAME isn't set and
CMake is always force to run again
Signed-off-by: Julien D'Ascenzio <julien.dascenzio@paratronic.fr>
A recent developer experience study has pointed out that it's very
common for people to miss that the minimum cmake version required by
zephyr is higher than that which is commonly packaged by Linux
distributions.
Since this is a serious usability issue, it's worth adding extra
checking from zcmake.py to make sure that west commands which run
cmake always print a sensible error message if the cmake version used
is too old. Make that happen.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Getting slightly subjective, but fixes this pylint warning:
scripts/west_commands/zcmake.py:186:13: R1714: Consider merging
these comparisons with "in" to "type_ in ('STRING', 'INTERNAL')"
(consider-using-in)
Use a set literal instead of a tuple literal, as recent Python 3
versions optimize set literals with constant keys nicely.
Getting rid of pylint warnings for a CI check. I could disable any
controversial ones (it's already a list of warnings to enable anyway).
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Making a clean slate for a pylint test in CI.
'_' is a common name for non-problematic unused variables in Python.
pylint knows not to flag it.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Analogously to the Make options with the same names, these print the
commands which would have run without running them.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Since west's main.py relies on the args tuple with the returncode
and the cmd, create the CalledProcessError using the correct
positional args.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Torsten Rasmussen