This reverts commit 043bb58488.
Note that scripts/requirements-actions.txt might not be 100% the same
as what was pinned prior to the revert due to it being difficult to
restore previous versions while also accounting for the new dependencies
that were added in the meantime.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Fixes#92059
Update getting started guide, migration-guide and
python.cmake to use Python 3.12.1 as minimum supported
version
Signed-off-by: Tu Nguyen Van <tu.nguyenvan@nxp.com>
Update getting started guide, release notes, CI actions and
Python version compliance check to use Python 3.12 as
minimum supported version.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Removes functions that would handle deprecated variables and
functionality from CMake within Zephyr that were deprecated in
Zephyr 3.1 onwards but before 3.7
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
The minimum Python version was bumped for Zephyr LTSv3, but only in the
documentation and CI. The build system would still accept Python 3.8,
yet some scripts in tree have already broken support with that version.
Incompatibility errors should be prevented early.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
When running cmake directly (without west, as twister does) on nix the
CMake environment paths are set and thus it does not find the
virtualenv'ed python. Fix this by ignoring the cmake environment
variables nix sets.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Fixes: #70258
Specify NO_CMAKE_PATH to prevent CMake find_program from having a
preference for searching CMAKE_PREFIX_PATH.
Some tool like NixOS / Nix package manager sets this variable
to point inside the nix store, like this:
CMAKE_PREFIX_PATH=/nix/store/gpvnsgf8zhqjjgk63dd...-python3-3.11.6-env
thus causing `find_program()` to prefer this over the tool in the
default path.
Support Nix environments by specifying NO_CMAKE_PATH and in addition
support `VIRTUAL_ENV` environment setting for search path when set by
the virtual environment.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
ERROR_QUIET should be used only when the command is actually expected to
fail, otherwise discarding stderr can be extremely time-consuming. See
recent example of time lost in commit 40c2e08e82 ("xcc/cmake: don't
discard stderr; don't (ever!) use ERROR_QUIET")
If some Python interpreter cannot even evaluate `sys.version_info[:2]`,
then we definitely don't want to hide what its stderr says about that.
Fixes commit 94de3e9f60 ("cmake: FindPython3: Adjust python3 program
search")
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
CMake 3.16 find_python3 module introduced `Python3_EXECUTABLE` as
artifact specifier.
This allows Zephyr to cleanup its Python detection mechanism and thus
remove the Zephyr specific `PYTHON_PREFER` variable, which is now
deprecated.
This further improves the Python detection mechanism in Zephyr as it
allows users to specify Python3_EXECUTABLE and thereby follows CMake
documentation.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Given that 3.6 is now several years old and the current and previous
Ubuntu LTS ship with 3.8 or later, upgrade the minimum required Python
version from 3.6 to 3.8.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Create a cmake/modules folder containing all Zephyr CMake modules.
All Zephyr cmake files that are included from boilerplate are now
converted into CMake modules which can be individually loaded.
The Zephyr CMake package is updated to support loading of individual
CMake modules using the COMPONENTS argument to `find_package(Zephyr)`.
If the COMPONENTS argument is not specified, the default Zephyr build
system will load.
If COMPONENTS is specified then, only those components and the
dependencies will be loaded.
If a Zephyr CMake module depends on another CMake module which has not
been loaded, it will automatically be loaded.
This allows us to modularize and reuse individual parts of the Zephyr
CMake build system in a more flexible way in future.
Such usage could be:
- Higher livel multi image build system
- Invocation of individual components, for example dts processing by
twister without loading all build code
- Doc build
- Unittesting
With this new CMake package and CMake module scheme then direct
sourcing of boilerplate.cmake has been deprecated.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #34368
Now added WEST_PYTHON to list of preferred pythons to check.
WEST_PYTHON is added after PYTHON_PREFER so that a user may still
request a specific python is used by supplying
`-DPYTHON_PREFER=<python>` even when building using `west build`.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #24692
This commit fixes an issue where FindPython3 could wrongly select the
Python version not in environment path.
If user installed both 32 and 64 bit versions of the same Python, for
example 3.7.x, the current search would only specify that 3.7 is needed.
In some cases, FindPython3 could select the 32 bit version, even if the
64 bit version is the one on %PATH%.
This is fixed, by setting Python3_ROOT_DIR to point to the tested Python
in %PATH%.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #24340
Using find_package(Python3 3.6) will select the highest available
python3.
This means that in case user has:
/usr/bin/python --> python2.7
/usr/bin/python3 --> python3.6
/usr/bin/python3.6
/usr/bin/python3.8
then CMake will choose python 3.8.
This commit changes that behavior, so that in the above scenario, then
Python 3.6 will be preferred.
It also adds the following, python will be preferred over python3, if
both meets the minimum requirement.
For example:
/usr/bin/python --> python3.6
/usr/bin/python3 --> python3.7
then Python 3.6 is prefered.
It further introduces PYTHON_PREFER variable, which can be used to
further control the behavior.
As example -DPYTHON_PREFER=python3.7 will choose Python 3.7 if
installed.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #23922, #24252, #11103
This commit switches to use the find_package(Python3) introduced with
CMake 3.12.
This removes the need for a Zephyr backport of Python detection module.
The search order for Python3 is following CMake search order and can be
controlled through CMake flags (See CMake documentation).
Default it will use the Python version found in PATH.
If multiple Python3 versions are found in PATH, the newest version will
be selected (Can be controlled using `Python3_FIND_STRATEGY`)
Using find_package(Python3) also ensures Python2.7 will never be
selected, issue #11103, which was re-introduced in Zephyr.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
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>
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>
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>
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>
Benjamin Cabé
Tu Nguyen Van
Jamie McCrae
Grzegorz Swiderski
Tom Burdick
Torsten Rasmussen
Marc Herbert
Carles Cufi
Martí Bolívar
Anas Nashif
Mark Ruvald Pedersen