| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
Considering we are not compatible with Python 2 anymore,
we can drop the 'object' explicit inheritance in the class
declaration.
Pick-to: 6.8
Change-Id: Iac3a95aa9721c3ff1a755f457c0936ca157a8470
Reviewed-by: Shyamnath Premnadh <Shyamnath.Premnadh@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
|
|
|
|
|
|
| |
Add a future statement to all Python source files.
Task-number: PYSIDE-2786
Change-Id: Icd6688c7795a9e16fdcaa829686d57792df27690
Reviewed-by: Adrian Herrmann <adrian.herrmann@qt.io>
|
| |
|
|
|
| |
Change-Id: I26c77eb6448ec539a33acea6d2f39678c2b089a3
Reviewed-by: Shyamnath Premnadh <Shyamnath.Premnadh@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removed mentions, comments, and fallback usages
in some sections of the build scripts and documentation.
On the CI, we upgrade setuptools in order to avoid having
missing functionality, so it shouldn't be an issue.
For Shiboken and CMake, there is still a helper that relies
on distutils in case people is using python < 3.8.2
Pick-to: 6.5
Change-Id: Ic33abe9fa8bd8564e9d44c8714b7fedd4e50434a
Reviewed-by: Simo Fält <simo.falt@qt.io>
|
| |
|
|
|
|
|
| |
- convert PosixPath to str, for the modified line
Change-Id: I358eba0af939726615ece3874de1852299e735ca
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
- some regression from 2afcf8e7545c681e412e5b6d04ab8867e5edd5c7
pathlib changes
Pick-to: 6.4
Change-Id: I32173bdffc1280e23b11006466f3dfb19a49fd8f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
|
| |
|
|
|
|
|
|
|
| |
There is a usage of os.path.relpath that cannot be migrated
to pathlib, which remain the only usage of os.path
Task-number: PYSIDE-2080
Change-Id: Iac781e9c9324fb8b9d3559b4225912d56782072a
Reviewed-by: Christian Tismer <tismer@stackless.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Replaced various dsitutils leftovers:
- distutils.cmd.Command by setuptools.Command
- distutils.command.build by setuptools.command.build
- distutils.sysconfig.get_python_lib(1) by sysconfig.get_paths()['platlib']
Task-number: PYSIDE-2079
Change-Id: Ia694629476f25019f4a9f8d3b306b0367a5cdb08
Reviewed-by: Christian Tismer <tismer@stackless.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
Adding simple logger based on the logging module
to replace the distutils.log one.
Task-number: PYSIDE-2079
Change-Id: I2a4996a57be701552005b57d2b1a251b9fc44c41
Reviewed-by: Christian Tismer <tismer@stackless.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
|
|
|
|
|
|
| |
Replacing the distutils errors by the setuptools one.
Task-number: PYSIDE-2079
Change-Id: I9968d9562f8dd40317344d3295943c194e3f2197
Reviewed-by: Christian Tismer <tismer@stackless.com>
|
| |
|
|
|
|
|
|
|
| |
Avoid accessing elements from sequences by index
without being explicit about all the returns from functions.
Pick-to: 6.2 6.3
Change-Id: I1cddda7f8c38724907cad854ee99489058dae5f3
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
Internally, we were using many words like 'filter', 'vars',
and 'dir' which are built-in functions in Python.
To avoid confusion and a possible wrong behavior, we renamed them.
Pick-to: 6.2 6.3
Change-Id: Idbadda3857705ef3a5f0440112ee923d3a61ffa0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
| |
Replace the current license disclaimer in files by a
SPDX-License-Identifier. Files that have to be modified by hand are
modified. License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: I065150015bdb84a3096b5b39c061cf0a20ab637d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
|
| |
|
|
|
|
| |
Pick-to: 6.3
Change-Id: Ie56b054ca32869a488356b31eea49cc985fc463e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
The PyPy implementation for Python 3.9 changed the version
for libpypy3-c.dylib a bit into libpypy3.9-c.dylib .
Change-Id: I7c004ccc91ec4e8647fe020b7e9286437ac93614
Pick-to: 6.3
Task-number: PYSIDE-353
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
| |
- Fixing f-strings
- Fixing indentation of some lines
- Removing unused variables and imports
- Changing the way of verifying if sphinx is installed
Change-Id: I3f361759682324c9b0c9d33c24583435f137f05a
Pick-to: 6.2
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
setup.py can now be used to cross-compile PySide to a target Linux
distribution from a Linux host.
For example you could cross-compile PySide targeting an arm64
Raspberry Pi4 sysroot on an Ubuntu x86_64 host machine.
Cross-compiling PySide has a few requirements:
- a sysroot to cross-compile against, with a pre-installed Qt,
Python interpreter, library and development packages (which
provides C++ headers)
- a host Qt installation of the same version that is in the target
sysroot
- a host Python installation, preferably of the same version as the
target one (to run setup.py)
- a working cross-compiling toolchain (cross-compiler, linker, etc)
- a custom written CMake toolchain file
- CMake version 3.17+
- Qt version 6.3+
The CMake toolchain file is required to set up all the relevant
cross-compilation information: where the sysroot is, where the
toolchain is, the compiler name, compiler flags, etc.
Once are requirements are met, to cross-compile one has to specify a
few additional options when calling setup.py: the path to the cmake
toolchain file, the path to the host Qt installation
and the target python platform name.
An example setup.py invocation to build a wheel for an armv7 machine
might look like the following:
python setup.py bdist_wheel --parallel=8 --ignore-git --reuse-build
--cmake-toolchain-file=$PWD/rpi/toolchain_armv7.cmake
--qt-host-path=/opt/Qt/6.3.0/gcc_64
--plat-name=linux_armv7l
--limited-api=yes
--standalone
Sample platform names that can be used are: linux_armv7, linux_aarch64.
If the auto-detection code fails to find the target Python or Qt
installation, one can specify their location by providing the
--python-target-path=<path>
and
--qt-target-path=<path>
options to setup.py.
If the automatic build of the host shiboken code generator fails,
one can specify the path to a custom built host shiboken via the
--shiboken-host-path option.
Documentation about the build process and a sample CMake
toolchain file will be added in a separate change.
Implementation details.
Internally, setup.py will build a host shiboken executable using
the provided host Qt path, and then use it for the cross-build.
This is achieved via an extra setup.py sub-invocation with some
heuristics on which options should be passed to the sub-invocation.
The host shiboken is not included in the target wheels.
Introspection of where the host / target Qt and Python are located
is done via CMake compile tests, because we can't query information
from a qmake that is built for a different architecture / platform.
When limited API is enabled, we modify the wheel name to contain the
manylinux2014 tag, despite the wheel not fully qualifying for that
tag.
When copying the Qt libraries / plugins from the target sysroot in a
standalone build, we need to adjust all their rpaths to match the
destination directory layout of the wheel.
Fixes: PYSIDE-802
Task-number: PYSIDE-1033
Change-Id: I6e8c51ef5127d85949de650396d615ca95194db0
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building the project using setup.py, it would pollute
the source directory with a lot of virtual environment build
directories.
Move all of those into a common 'build' subdirectory.
This eases cleanup of all build directories because they
can all be removed with a single rm command.
It also places all the various stages of build -> install -> package
folders into a common subdirectory so it's easier to find and navigate
between them.
If no virtualenv is detected, change the venv prefix from the previous
value of 'pyside' to 'qfp' and include the build classifiers.
If a virtualenv is detected, we consider it is distinct enough and
don't include the build classifiers, apart from a few chars to denote
a debug python, debug Qt or limited api build.
Example of the new build directory structure when a virtualenv is
detected
build/{venv_name}/build/shiboken6
build/{venv_name}/build/pyside6
build/{venv_name}/install/bin/shiboken6
build/{venv_name}/package
Example of the new build directory structure when a virtualenv is
NOT detected
build/qfp-py3.9-qt6.2.0-64bit-release/build/shiboken6
build/qfp-py3.9-qt6.2.0-64bit-release/build/pyside6
build/qfp-py3.9-qt6.2.0-64bit-release/install/bin/shiboken6
build/qfp-py3.9-qt6.2.0-64bit-release/package
Move the code that always removed the ./build directory on each
setup.py invocation into prepare_packages() instead.
This way it only removes the files from the 'package' subfolder which
is the common packaging location between all the sub-projects.
This removal is needed to ensure shiboken files don't end up packaged
in the PySide6 wheel.
This relands commit 234349d124ccfa399921e2b9fc09addcff0b0a94
This reverts commit 0c6eb7cd232fff9d81a8d5bc9a7fd71d9b8c67f5
[ChangeLog][setup.py] Build directories are now created inside the
root ./build directory, rather than directly under the root of the
project.
Pick-to: 6.2
Change-Id: I6d511ae77cb66c2c5a872d6b85ff33e1831b803e
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
|
|
|
... as well as install dir, setuptools package dir and other common
build path information we compute.
This paves the way to reland 234349d124ccfa399921e2b9fc09addcff0b0a94
which was reverted in 0c6eb7cd232fff9d81a8d5bc9a7fd71d9b8c67f5
To do that, move the various build info computation into a separate
mixin class that computes and assigns the values in
PysideBuild.finalize_options() rather than run().
This ensures that PysideInstall and PysideBuildWheel inherit the same
build dir / install dirs by querying the info from the build command.
Pick-to: 6.2
Change-Id: I802f122ddf3eb1e9daff25fac4d697f2ceae8e0c
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
|