| 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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PySide project has been split into three pieces, including
Shiboken. This had far-reaching consequences for the signature project.
Shiboken can be run together with PySide or alone,
with tests or without. In every configuration, the signature
module has to work correctly.
During tests, the shiboken binary also hides the shiboken module,
and we had to use extra efforts to always guarantee the accessibility
of all signature modules.
This commit is the preparation for typeerrors implemented with the
signature module. It has been split off because the splitting
is not directly related, besides these unawaited consequences.
I re-added and corrected voidptr_test and simplified the calls.
Remark.. We should rename shiboken to Shiboken in all imports.
I also simplified initialization. After "from PySide2 import QtCore",
now a simple access like "type.__signature__" triggers initialization.
Further, I removed all traces of "signature_loader" and allowed
loading everything from PySide2.support.signature, again. The
loader is now needed internally, only.
Also, moved the type patching into FinishSignatureInitialization
to support modules with no classes at all.
The "testbinding" problem was finally identified as a name clash
when the same function is also a signal. A further investigation
showed that there exists also a regular PySide method with
that problem. The test was extended to all methods, and it
maps now all these cases to "{name}.overload".
Updated the included typing27.py from https://pypi.org/project/typing/
from version 3.6.2 to version 3.6.6 .
Task-number: PYSIDE-749
Change-Id: Ie33b8c6b0df5640212f8991539088593a041a05c
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Once the qtbase commit
(22c1a46a03bc3347afc0e7462e19558283d0e1b7) gets integrated into
the qt/qt5 repo for dev branch, we can revert the terrible
workaround fix, because it won't be needed anymore.
This reverts commit 5cd52cda24bf70bf99f4deec037039df0ab928f5.
Task-number: PYSIDE-724
Change-Id: I627c7ec945b864a1c16ba6cd7288807591f70140
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with Qt 5.12-ish (qtbase commit
c538a333db4b7526fb4d9a82c06296d2492bf000) the macOS QPA cocoa plugin
switched to using layer-backed NSViews.
For some unknown reason when building PySide2
with a python.org official interpreter and the above commit, none
of the QWidget / NSViews get drawn (-[QNSView drawRect:] is not
called).
Using an older qtbase with the same official interepreter works.
Using the same qtbase with a custom built interpreter works.
Using the same qtbase with a custom built interpreter which is the
same version as the official one (3.6.5 at the moment) works
(built from v3.6.5 source package published on the downloads page).
Using the same qtbase with official interpeter does NOT work.
Python2 vs Python3 does not matter.
Release vs Debug does not matter.
I have not been able to build an interpreter with the minimum
deployment target set to 10.6 as the official package does (but
rather 10.12), so this is still an avenue to try.
The terrible workaround is to disable layer-backed views via an
environment variable when running testrunner (QT_MAC_WANTS_LAYER).
All users would have to do the same for their own applications,
otherwise they will not work.
Change-Id: Ia9a34f1e7b0b1b4807030cc7acecbefc8f344e84
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces tracking of modules for which bindings will not
be built. This allows us to add conditions on disabled modules,
and thus disable certain tests.
Thus we disable pysidetest test when its dependencies are not met.
Due to this, we can now builtd bindings only for QtCore,
allowing faster development iteration when touching only QtCore.
Note that this only affects which module bindings will be created.
Shiboken itself still requires QtCore, QtXml and QtXmlPatterns,
as does pyside2-rcc.
Change-Id: I75084a1741e7f4c3594e43af0fd9668a0e969c56
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Setting owner as default to not allow Python to create a copy
of the QPixmap associated with the QLabel.
The C++ object pointer is acquired through the pixmap() method.
A test case was included.
Task-number: PYSIDE-150
Change-Id: Ie6975c39cbf49a59ebd478db0e1a0c30fc14864a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When Qt launches the QXcbEventReader thread, by default the created
thread dispatcher will call g_thread_init_glib to initialize the glib
thread. When libqgtk2 plugin is loaded, the plugin calls gtk_init
which also needs to initialize the glib thread library.
This can cause a race condition where the xcb thread might not finish
initializing all of the glib thread library, but the main thread
believes that initializing is done, and thus ends up dereferencing
null pointers.
Specifically when the glib function g_slice_alloc is called in the main
thread, which calls allocator_categorize, the glib initialization flag
'sys_page_size' is checked. This flag can already be set by the call
to g_slice_init_nomessage in the xcb thread, but magazine_mutex might not
yet be allocated (in g_slice_thread_init_nomessage), and the main
thread ends up dereferencing a null pointer mutex.
Relevant code can be found at
https://sourcecodebrowser.com/glib2.0/2.27.4/gslice_8c_source.html
The workaround is to set the QT_NO_GLIB environment variable
to 1 when running the tests, so that a regular
QEventDispatcherUNIX is used. Thus only the gtk plugin will call the
glib initialization function, eliminating the race condition.
Note that the issue probably happens only for glib versions < 2.32.
The g_thread_init function is deprecated since 2.32, and glib thread
initialization is done at the start of the program, as referenced at
https://developer.gnome.org/glib/2.32/glib-Deprecated-Thread-APIs.html#g-thread-init
Task-number: QTBUG-64716
Change-Id: Ibcccf8f6e0a3299e61dd320eb6d08e29658298e2
Reviewed-by: Christian Tismer <tismer@stackless.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the signature module, it is now a straight forward task
to generate a registry of all known function signatures.
We check that these signatures all exist.
One file contains all signatures for one platform and version.
The test is only activated when run in the CI system.
An initial call creates the expected file as output and raises
an error. The result can then be picked up from the error log
and added to the repository.
Done: linux2 5.6.4
Done: darwin 5.6.4
Done: win32 5.6.4
Task-number: PYSIDE-510
Change-Id: I4f406cf72d25fdd2336814f6f20129079b8be54f
Reviewed-by: Christian Tismer <tismer@stackless.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is achieved by registering a qt.conf file with a Prefix pointing
to a directory relative to the loaded PySide2 module (e.g. QtCore).
Thus Qt does not crash due to not finding platform plugins.
Because this change would affect tests, which are ran before the
PySide package is installed, a new environment variable called
PYSIDE_DISABLE_INTERNAL_QT_CONF is introduced. This variable disables
the registration of the internal qt.conf file, thus it will not point
to a not yet created location, which will allow tests to run as
before.
Change-Id: I5a96037adfafe1f08ea57535aa4a2a0d1660dfaf
Task-number: PYSIDE-558
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Christian Tismer <tismer@stackless.com>
|
|
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.
|