| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a CMake super project that includes the shiboken2, PySide2 and
pyside2-tools subprojects, so that it's possible to build everything
from Qt Creator (or any other IDE that supports CMake)
with minimal set up effort, and thus inform the IDE CMake integration
of all relevant files, for easier code editing, navigation and
refactoring.
This also lays the foundation for allowing 3rd parties to use the
shiboken2 generator to generate custom modules. This is
achieved by eliminating various hardcoded paths for libraries and
include directories.
Start using CMake targets throughout the build code to correctly
propagate link flags and include dirs for libshiboken and
shiboken2 executable targets. Same for the libpyside target.
Generate two separate cmake config files (build-tree / install-tree)
that can be used with find_package(Shiboken2), to make sure that
the PySide2 project can be built as part of the super project build.
This is currently the only way I've found to allow the super build
to work.
Note that for the build-tree find_package() to work, the
CMAKE_MODULE_PATH has to be adjusted in the super project file.
The generated config files contain variables and logic that allow
usage of the installed shiboken package in downstream projects
(PySide2). This involves things like getting the includes and
libraries for the currently found python interpreter, the shiboken
build type (release or debug), was shiboken built with limited
api support, etc.
Generate 2 separate (build-tree and install-tree) config files
for PySide2, similar to how it's done for the shiboken case, for
pyside2-tools to build correctly.
Install shiboken2 target files using install(EXPORT)
to allow building PySide2 with an installed Shiboken2 package
(as opposed to one that is built as part of the super project).
Same with PySide2 targets for pyside2-tools subproject.
Make sure not to redefine uninstall targets if they are already
defined.
Add a --shorter-paths setup.py option, which would be used by
the Windows CI, to circumvent creating paths that are too long,
and thus avoiding build issues.
Output the build characteristics / classifiers into the generated
build_history/YYYY-MM-DD_AAAAAA/build_dir.txt file, so it can be
used by the test runner to properly filter out blacklisted
tests. This was necessary due to the shorter paths options.
Fix various issues regarding target includes and library
dependencies.
Remove certain duplicated cmake code (like limited api check and build
type checks) in PySide2, given that that information will now be
present in the exported shiboken2 config file.
Include a short README.cmake.md file that describes how to build
the super project.
References used
https://rix0r.nl/blog/2015/08/13/cmake-guide/
https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/
https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
https://cliutils.gitlab.io/modern-cmake/chapters/basics/functions.html
https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html
https://github.com/ComicSansMS/libstratcom/blob/master/CMakeLists.txt
Abandoned approach using ExternalProject references:
https://cmake.org/cmake/help/latest/module/ExternalProject.html
https://stackoverflow.com/questions/44990964/how-to-perform-cmakefind-package-at-build-stage-only
Fixes: PYSIDE-919
Change-Id: Iaa15d20b279a04c5e16ce2795d03f912bc44a389
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Actually this creates 3 wheel packages:
- shiboken2 (the python module and libshiboken shared library)
- shiboken2-generator (contains the generator executable, libclang and
dependent Qt libraries)
- PySide2 (the PySide2 modules and Qt shared libraries, and tools like
rcc, uic)
Calling the setup.py script will not do the actual build now (in the
sense of calling CMake, make, etc.). Instead it will spawn new
processes (via subprocess.call) calling the same setup.py script,
but with different arguments. These "sub-invocations" will do the
actual building. Thus, the "top-level invocation" will decide which
packages to build and delegate that to the "sub-invocations" of
setup.py.
A new optional command line argument is introduced called
"--build-type" which defaults to "all", and can also be set to
"shiboken2", "shiboken2-generator" and "pyside2". A user can choose
which packages to build using this option. The "top-level invocation"
uses this option to decide how many "sub-invocations" to execute.
A new command line argument called "--internal-build-type"
takes the same values as the one above. It defines which package
will actually be built in the new spawned "sub-invocation" process.
The "top-level invocation" sets this automatically for each
"sub-invocation" depending on the value of "--build-type".
This option is also useful for developers that may want to debug the
python building code in the "sub-invocation".
Developers can set this manually via the command line, and
thus avoid the process spawning indirection.
A new class Config is introduced to facilitate storage of
the various state needed for building a single package.
A new class SetupRunner is introduced that takes care of the
"--build-type" and "--internal-build-type" argument handling
and delegation of "sub-invocations".
A new class Options is introduced to 'hopefully', in the future, streamline
the mess of option handling that we currently have.
setup.py now is now simplified to mostly just call
SetupRunner.run_setup().
Certain refactorings were done to facilitate further clean-up of the
build code, the current code is definitely not the end all be all.
Various other changes that were needed to implement the wheel
separation:
- a new cmake_helpers directory is added to share common cmake
code between packages.
- the custom popenasync.py file is removed in favor of using
subprocess.call in as many places as possible, and thus
avoid 10 different functions for process creation.
- Manifest.in is removed, because copying to the setuptools
build dir is now done directly by prepare_packages functions.
- because prepare_packages copies directly to the setuptools
build dir, avoiding the pyside_package dir, we do less copying
of big Qt files now.
- versioning of PySide2 and shiboken2 packages is now separate.
shiboken2 and shiboken2-generator share the same versions for
now though.
- shiboken2 is now listed as a required package for PySide2, to
facilitate pip requirements.txt dependencies.
- coin_build_instructions currently needs to install an unreleased
version of wheel, due to a bug that breaks installation of
generated wheel files.
- added separate command line options to pyside2_config.py for
shiboken2-module and shiboken2-generator.
- adapted samplebinding and scriptableapplication projects due to
shiboken being a separate package.
- adapted pyside2-tool and shiboken2-tool python scripts for setup
tools entry points.
- made some optimizations not to invoke cmake for shiboken2-generator
when doing a top-level "all" build.
- fixed unnecessary rpaths not to be included on Linux (mainly the
Qt rpaths).
Task-nubmer: PYSIDE-749
Change-Id: I0336043955624c1d12ed254802c442608cced5fb
Reviewed-by: Christian Tismer <tismer@stackless.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
in preparation for a subtree merge.
this should not be necessary to do in a separate commit, but git is a
tad stupid about following history correctly without it.
|
