2019-04-06 15:08:09 +02:00
|
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
|
|
2019-01-14 17:21:23 +01:00
|
|
|
include(${ZEPHYR_BASE}/cmake/toolchain/zephyr/host-tools.cmake)
|
2017-10-27 15:43:34 +02:00
|
|
|
|
2020-04-29 19:21:20 +02:00
|
|
|
# west is an optional dependency
|
2018-11-12 15:23:51 +01:00
|
|
|
find_program(
|
|
|
|
|
WEST
|
|
|
|
|
west
|
|
|
|
|
)
|
|
|
|
|
if(${WEST} STREQUAL WEST-NOTFOUND)
|
|
|
|
|
unset(WEST)
|
2019-03-11 21:42:31 +01:00
|
|
|
else()
|
|
|
|
|
# If west is found, make sure its version matches the minimum
|
|
|
|
|
# required one.
|
2020-02-26 19:34:42 +01:00
|
|
|
set(MIN_WEST_VERSION 0.7.1)
|
2019-03-11 21:42:31 +01:00
|
|
|
execute_process(
|
|
|
|
|
COMMAND
|
2019-11-05 16:54:20 +01:00
|
|
|
${PYTHON_EXECUTABLE}
|
|
|
|
|
-c
|
|
|
|
|
"import west.version; print(west.version.__version__, end='')"
|
|
|
|
|
OUTPUT_VARIABLE west_version
|
|
|
|
|
RESULT_VARIABLE west_version_output_result
|
2019-03-11 21:42:31 +01:00
|
|
|
)
|
|
|
|
|
|
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-06-08 21:09:15 +02:00
|
|
|
if(WEST_PYTHON)
|
|
|
|
|
if(NOT (${WEST_PYTHON} STREQUAL ${PYTHON_EXECUTABLE}))
|
|
|
|
|
set(PYTHON_EXECUTABLE_OUT_OF_SYNC "\nNote:\n\
|
|
|
|
|
The Python version used by west is: ${WEST_PYTHON}\n\
|
|
|
|
|
The Python version used by CMake is: ${PYTHON_EXECUTABLE}\n\
|
|
|
|
|
This might be correct, but please verify your installation.\n")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
2019-11-05 16:54:20 +01:00
|
|
|
if(west_version_output_result)
|
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-06-08 21:09:15 +02:00
|
|
|
message(FATAL_ERROR "Unable to import west.version from '${PYTHON_EXECUTABLE}'\n\
|
|
|
|
|
Please install with:\n\
|
|
|
|
|
${PYTHON_EXECUTABLE} -m pip install west\
|
|
|
|
|
${PYTHON_EXECUTABLE_OUT_OF_SYNC}")
|
2019-11-05 16:54:20 +01:00
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(${west_version} VERSION_LESS ${MIN_WEST_VERSION})
|
|
|
|
|
message(FATAL_ERROR "The detected west version is unsupported.\n\
|
2019-03-11 21:42:31 +01:00
|
|
|
The version was found to be ${west_version}:\n\
|
|
|
|
|
${item}\n\
|
|
|
|
|
But the minimum supported version is ${MIN_WEST_VERSION}\n\
|
2019-11-05 16:54:20 +01:00
|
|
|
Please upgrade with:\n\
|
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-06-08 21:09:15 +02:00
|
|
|
${PYTHON_EXECUTABLE} -m pip install --upgrade west\
|
|
|
|
|
${PYTHON_EXECUTABLE_OUT_OF_SYNC}")
|
2019-11-05 16:54:20 +01:00
|
|
|
endif()
|
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-06-08 21:09:15 +02:00
|
|
|
|
2019-03-11 21:42:31 +01:00
|
|
|
# Just output information for a single version. This will still work
|
|
|
|
|
# even after output is one line.
|
|
|
|
|
message(STATUS "Found west: ${WEST} (found suitable version \"${west_version}\", minimum required is \"${MIN_WEST_VERSION}\")")
|
2019-06-12 01:57:37 +02:00
|
|
|
|
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-06-08 21:09:15 +02:00
|
|
|
execute_process(
|
|
|
|
|
COMMAND ${PYTHON_EXECUTABLE} -c
|
2020-07-09 22:04:10 +02:00
|
|
|
"import pathlib; from west.util import west_topdir; print(pathlib.Path(west_topdir()).as_posix())"
|
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-06-08 21:09:15 +02:00
|
|
|
OUTPUT_VARIABLE WEST_TOPDIR
|
|
|
|
|
OUTPUT_STRIP_TRAILING_WHITESPACE
|
|
|
|
|
WORKING_DIRECTORY ${ZEPHYR_BASE}
|
|
|
|
|
)
|
2018-11-12 15:23:51 +01:00
|
|
|
endif()
|
|
|
|
|
|
2020-04-29 19:21:20 +02:00
|
|
|
# dtc is an optional dependency
|
2017-10-27 15:43:34 +02:00
|
|
|
find_program(
|
|
|
|
|
DTC
|
|
|
|
|
dtc
|
|
|
|
|
)
|
|
|
|
|
|
2020-01-27 14:55:18 +01:00
|
|
|
if(DTC)
|
2020-04-29 19:21:43 +02:00
|
|
|
# Parse the 'dtc --version' output to find the installed version.
|
|
|
|
|
set(MIN_DTC_VERSION 1.4.6)
|
|
|
|
|
execute_process(
|
|
|
|
|
COMMAND
|
|
|
|
|
${DTC} --version
|
|
|
|
|
OUTPUT_VARIABLE dtc_version_output
|
2020-06-12 12:16:00 +02:00
|
|
|
ERROR_VARIABLE dtc_error_output
|
|
|
|
|
RESULT_VARIABLE dtc_status
|
2020-04-29 19:21:43 +02:00
|
|
|
)
|
|
|
|
|
|
2020-06-12 12:16:00 +02:00
|
|
|
if(${dtc_status} EQUAL 0)
|
|
|
|
|
string(REGEX MATCH "Version: DTC ([0-9]+[.][0-9]+[.][0-9]+).*" out_var ${dtc_version_output})
|
|
|
|
|
|
|
|
|
|
# Since it is optional, an outdated version is not an error. If an
|
|
|
|
|
# outdated version is discovered, print a warning and proceed as if
|
|
|
|
|
# DTC were not installed.
|
|
|
|
|
if(${CMAKE_MATCH_1} VERSION_GREATER ${MIN_DTC_VERSION})
|
|
|
|
|
message(STATUS "Found dtc: ${DTC} (found suitable version \"${CMAKE_MATCH_1}\", minimum required is \"${MIN_DTC_VERSION}\")")
|
|
|
|
|
else()
|
|
|
|
|
message(WARNING
|
|
|
|
|
"Could NOT find dtc: Found unsuitable version \"${CMAKE_MATCH_1}\", but required is at least \"${MIN_DTC_VERSION}\" (found ${DTC}). Optional devicetree error checking with dtc will not be performed.")
|
|
|
|
|
set(DTC DTC-NOTFOUND)
|
|
|
|
|
endif()
|
2020-04-29 19:21:43 +02:00
|
|
|
else()
|
|
|
|
|
message(WARNING
|
2020-06-12 12:16:00 +02:00
|
|
|
"Could NOT find working dtc: Found dtc (${DTC}), but failed to load with:\n ${dtc_error_output}")
|
2020-04-29 19:21:43 +02:00
|
|
|
set(DTC DTC-NOTFOUND)
|
|
|
|
|
endif()
|
2018-10-18 13:13:03 +02:00
|
|
|
endif()
|
|
|
|
|
|
2020-01-29 15:39:33 +01:00
|
|
|
# gperf is an optional dependency
|
2017-10-27 15:43:34 +02:00
|
|
|
find_program(
|
|
|
|
|
GPERF
|
|
|
|
|
gperf
|
|
|
|
|
)
|
|
|
|
|
|
2017-11-08 19:20:55 +01:00
|
|
|
# openocd is an optional dependency
|
|
|
|
|
find_program(
|
|
|
|
|
OPENOCD
|
|
|
|
|
openocd
|
|
|
|
|
)
|
|
|
|
|
|
2018-06-01 08:37:28 +02:00
|
|
|
# bossac is an optional dependency
|
|
|
|
|
find_program(
|
|
|
|
|
BOSSAC
|
|
|
|
|
bossac
|
|
|
|
|
)
|
|
|
|
|
|
2017-10-27 15:43:34 +02:00
|
|
|
# TODO: Should we instead find one qemu binary for each ARCH?
|
|
|
|
|
# TODO: This will probably need to be re-organized when there exists more than one SDK.
|
