OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/cmake/python.cmake

23 lines
927 B
CMake
Raw Normal View History

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-06 21:08:09 +08:00
# SPDX-License-Identifier: Apache-2.0
cmake: Instruct Python to use UTF-8 on Windows In order for CMake and Python to interact correctly when the former invokes the latter, ensure that Python uses UTF-8 encodings when interacting with stdout and stdin on Windows. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2019-07-25 17:37:32 +08:00
# On Windows, instruct Python to output UTF-8 even when not
# interacting with a terminal. This is required since Python scripts
# are invoked by CMake code and, on Windows, standard I/O encoding defaults
# to the current code page if not connected to a terminal, which is often
# not what we want.
if (WIN32)
set(ENV{PYTHONIOENCODING} "utf-8")
endif()
cmake: boilerplate: Move out finding git+python to separate cmake files Follow the same convention as that of ccache. Improve readability of boilerplate.cmake file. Move inclusion of version.cmake up to satisfy git.cmake dependency. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-11-27 06:39:51 +08:00
# The 'FindPythonInterp' that is distributed with CMake 3.8 has a bug
# that we need to work around until we upgrade to 3.13. Until then we
# maintain a patched copy in our repo. Bug:
# https://github.com/zephyrproject-rtos/zephyr/issues/11103
cmake: require python 3.6 or later Zephyr currently requires Python 3.4 or later. The core Python team declared version 3.4 hit End of Life (EOL) in March, so there's no reason to continue to support it if that's causing a burden, which it is. This commit allows Zephyr's Python scripts to depend on features present in version 3.6 or later. This does skip support for a currently active version of Python: - Python 3.5 is actively supported by the core Python devs until 09/2020 - Zephyr's 2.2 release, the first which could include this change, is tentatively scheduled for 02/2020. However, almost all supported platforms are either unaffected, or their users can upgrade easily: - Windows users who need to can upgrade Python with: choco upgrade python - macOS users who need to can upgrade Python with: brew upgrade python3 - Red Hat Enterprise Linux users who need to upgrade can use Software Collections (SCLs), e.g. as described here: https://developers.redhat.com/blog/2018/08/13/install-python3-rhel/ - CentOS Linux users also have access to SCLs, as described here: https://wiki.centos.org/AdditionalResources/Repositories/SCL - Ubuntu's current long-term support (LTS) release (Bionic Beaver, version 18.04) ships with Python 3.6. It and all later versions of Ubuntu won't be affected by this change. - Debian's current stable release (Buster, version 10) ships Python 3.7 and likewise won't be affected. The impact of this change is therefore biggest for older versions of Linux. In particular, these are impacted: - Older Ubuntu LTS releases. - Ubuntu 16.04 ships Python 3.5; it is still supported by Canonical. - Ubuntu 14.04 ships Python 3.4, which is EOL. This Ubuntu version is also no longer getting standard support from Canonical. Paying customers are receiving security updates only. https://wiki.ubuntu.com/Releases - Older Debian versions. - Debian 9 (stretch) ships Python 3.5 and is still a supported Debian version. - Debian 8 (jessie) ships Python 3.4, which is EOL. This Debian version is no longer receiving mainline maintenance by the Debian project. LTS updates are provided by interested community volunteers only. https://wiki.debian.org/LTS Affected Linux users will no longer have a system Python 3 which works "out of the box" with Zephyr after this change. Some ideas for these users are: - Use Zephyr v2.1 or v1.14 LTS, which are maintained and still support Python 3.4 - Compile Python 3.6 or later from source and use it within a venv: https://docs.python.org/3/library/venv.html - Use something like https://github.com/pyenv/pyenv Python 3.6 has compelling new features which make writing Zephyr's scripts easier, and which it would be good to be able to rely upon. This motivates moving from Python 3.4 to 3.6 instead of 3.5. My personal killer 3.6 features motivating skipping 3.5 (YMMV): - Windows console and file system encodings are UTF-8 (PEPs 528 and 529): Zephyr's scripts, and many utilities related to git, broadly assume strings are UTF-8, so this is very helpful - os.PathLike and the file system path protocol (PEP 519) allow intermixing "smart" paths in pathlib with existing os.path based code - f-strings (PEP 0498) are a wonderful and efficient string interpolation mechanism - CPython dictionaries are insertion ordered as an implementation detail starting with 3.6, which in practice helps with reproducibility (and *all* Python implementations have insertion ordered dicts starting with 3.7) Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2019-12-06 02:20:08 +08:00
set(PythonInterp_FIND_VERSION 3.6)
cmake: boilerplate: Move out finding git+python to separate cmake files Follow the same convention as that of ccache. Improve readability of boilerplate.cmake file. Move inclusion of version.cmake up to satisfy git.cmake dependency. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-11-27 06:39:51 +08:00
set(PythonInterp_FIND_VERSION_COUNT 2)
set(PythonInterp_FIND_VERSION_MAJOR 3)
cmake: require python 3.6 or later Zephyr currently requires Python 3.4 or later. The core Python team declared version 3.4 hit End of Life (EOL) in March, so there's no reason to continue to support it if that's causing a burden, which it is. This commit allows Zephyr's Python scripts to depend on features present in version 3.6 or later. This does skip support for a currently active version of Python: - Python 3.5 is actively supported by the core Python devs until 09/2020 - Zephyr's 2.2 release, the first which could include this change, is tentatively scheduled for 02/2020. However, almost all supported platforms are either unaffected, or their users can upgrade easily: - Windows users who need to can upgrade Python with: choco upgrade python - macOS users who need to can upgrade Python with: brew upgrade python3 - Red Hat Enterprise Linux users who need to upgrade can use Software Collections (SCLs), e.g. as described here: https://developers.redhat.com/blog/2018/08/13/install-python3-rhel/ - CentOS Linux users also have access to SCLs, as described here: https://wiki.centos.org/AdditionalResources/Repositories/SCL - Ubuntu's current long-term support (LTS) release (Bionic Beaver, version 18.04) ships with Python 3.6. It and all later versions of Ubuntu won't be affected by this change. - Debian's current stable release (Buster, version 10) ships Python 3.7 and likewise won't be affected. The impact of this change is therefore biggest for older versions of Linux. In particular, these are impacted: - Older Ubuntu LTS releases. - Ubuntu 16.04 ships Python 3.5; it is still supported by Canonical. - Ubuntu 14.04 ships Python 3.4, which is EOL. This Ubuntu version is also no longer getting standard support from Canonical. Paying customers are receiving security updates only. https://wiki.ubuntu.com/Releases - Older Debian versions. - Debian 9 (stretch) ships Python 3.5 and is still a supported Debian version. - Debian 8 (jessie) ships Python 3.4, which is EOL. This Debian version is no longer receiving mainline maintenance by the Debian project. LTS updates are provided by interested community volunteers only. https://wiki.debian.org/LTS Affected Linux users will no longer have a system Python 3 which works "out of the box" with Zephyr after this change. Some ideas for these users are: - Use Zephyr v2.1 or v1.14 LTS, which are maintained and still support Python 3.4 - Compile Python 3.6 or later from source and use it within a venv: https://docs.python.org/3/library/venv.html - Use something like https://github.com/pyenv/pyenv Python 3.6 has compelling new features which make writing Zephyr's scripts easier, and which it would be good to be able to rely upon. This motivates moving from Python 3.4 to 3.6 instead of 3.5. My personal killer 3.6 features motivating skipping 3.5 (YMMV): - Windows console and file system encodings are UTF-8 (PEPs 528 and 529): Zephyr's scripts, and many utilities related to git, broadly assume strings are UTF-8, so this is very helpful - os.PathLike and the file system path protocol (PEP 519) allow intermixing "smart" paths in pathlib with existing os.path based code - f-strings (PEP 0498) are a wonderful and efficient string interpolation mechanism - CPython dictionaries are insertion ordered as an implementation detail starting with 3.6, which in practice helps with reproducibility (and *all* Python implementations have insertion ordered dicts starting with 3.7) Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2019-12-06 02:20:08 +08:00
set(PythonInterp_FIND_VERSION_MINOR 6)
cmake: boilerplate: Move out finding git+python to separate cmake files Follow the same convention as that of ccache. Improve readability of boilerplate.cmake file. Move inclusion of version.cmake up to satisfy git.cmake dependency. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-11-27 06:39:51 +08:00
set(PythonInterp_FIND_VERSION_EXACT 0)
set(PythonInterp_FIND_REQUIRED 1)
include(${ZEPHYR_BASE}/cmake/backports/FindPythonInterp.cmake)