| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The script is now automatically called in the cmake build,
as part of the create_pyside_module macro.
The script runs after every module build and tries to
generate .pyi files. This does not need to succeed, but
will generate all files in the end. The script has been prepared
to allow partial runs without overhead.
After integration of the .pyi generation into cmake, these files
are also installed into the install directory by cmake.
For wheel building, setup.py has entries, too.
Building a full project with all modules revealed a bug in the
signature module that allowed unsupported function objects.
Module enum_sig had to be changed to suppress types
which have no ancestry in shiboken.
PYTHONPATH was avoided because it was not Windows
compatible. Instead, the script was changed to accept
"--sys-path" and "--lib-path" parameters. The latter evaluates
either to PATH or LD_LIBRARY_PATH.
The necessity to create .pyi files while the project is in the
build process showed a hard to track down error condition
in PySide_BuildSignatureProps.
Simple logging was added as a start of introducing logging
everywhere.
Task-number: PYSIDE-735
Change-Id: I6b3eec4b823d026583e902023badedeb06fe0961
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implementation formats all signatures in a way
that is known as type hinting files (.pyi).
Usage
-----
The script is to be called by the same Python interpreter that
was used to build PySide. It works with Python 2 and 3.
On Python 3, it performs a self-test.
python3 sources/pyside2/PySide2/support/generate_pyi.py run
will generate .pyi files for all compiled PySide modules
and places them into site packages to the binaries.
An optional outpath can be specified.
It is planned to call this script automatically after install.
o Local constants are not included, yet.
Maybe they never will, unless requested.
o The keyword "from" appears 43 times in argument lists.
It is fixed in Python, only which does not matter.
o When using Python 3.7 or above, it respects Pep 563 and
avoids imports which are deferred to runtime.
Task-number: PYSIDE-735
Change-Id: I3bcd5d9284b853fe955376bf35c7897e3698da2b
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously whenever a typesystem XML file changed, this resulted in a
full rebuild of all cpp files generated for that particular module.
This change shifts the rules of building in such a way, that files
are rebuilt only if their content has changed.
XML modifications should generally not cause full
rebuilds anymore, unless the change is in a global header.
This is achieved in the following way, assuming a binding library
"foo" added by add_library(foo ...):
1) CMake calls shiboken via add_custom_command.
2) The OUTPUT file for the command is the generated
mjb_rejected_classes.log file, which serves as a timestamp
for when shiboken was last run.
3) All the generated cpp files are marked as "Generated" via the
add_custom_command BYPRODUCTS option. This allows the files
to have an older timestamp than that of an XML file, thus not
forcing constant shiboken re-execution.
4) A new custom target foo_generator is added via add_custom_target.
5) This target has a dependency on the mjb_rejected_classes.log file,
and the target itself is added as a dependency to the "foo" target.
6) Whenever "foo" is built, it will first try to build "foo_generator"
which will force the shiboken custom command to be run, which will
generate the cpp files and mjb_rejected_classes.txt file.
The BYPRODUCT cpp files can then be used as sources in the
"foo" target.
7) If a user modifies the XML file listed in the add_custom_command
DEPENDS option, this will re-trigger shiboken execution, which
will create a new mjb_rejected_classes.log file, which means that
the "foo" target might be rebuilt if, and only if, any of the cpp
file timestamps are new. Otherwise "foo" doesn't need to be
rebuilt.
Change-Id: I9a3844a2fa775106288acc01cb4570a903e16991
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces a new type into the shiboken2 module which is
imported by calling "import PySide2.support.VoidPtr".
The type takes care of conversions from / to void* values in function
signatures.
Creating an instance can be done by passing either a shiboken wrapped
object, or an integer representing an address, or a python object that
implements the buffer interface.
For example, this is useful for passing numpy arrays to C OpenGL
functions that take void* parameters. First you convert the array into
a bytestring (using numpy.array.tobytes(), then you instantiate a
VoidPtr from that bytestring, and finally you pass it along to a GL
function.
One corner case that is currently not supported is void** parameters.
Change-Id: I01e291d6856cb6bd8b5175adc3ead6b728036535
Reviewed-by: Christian Tismer <tismer@stackless.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the same imp.get_suffixes() mechanism as on Unix, to determine
the suffix part of module extension files.
This fixes debug builds to work on Windows.
Note that the whole build stack has to use the same configuration,
no mixing is allowed on Windows.
For release build you need: python.exe + setup.py without --debug
flag + release build of Qt5.
For debug build you need: python_d.exe + setup.py with --debug
flag + debug build of Qt5.
Change-Id: I6188c859b5757d11e87d6a9e32b9ba558f7f609e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change decouples the naming of general shared libraries, python
module extensions, and cmake configuration files. All of them are now
computed depending on the python version and python build
configuration, and can also be manually set via CMake variables.
The module extensions names now use the most detailed 'import' prefix,
which usually informs whether a debug or release python was used, or
the Python ABI flags (for Python >= 3.2).
When a debug Python interpreter is used for building PySide2, the
preprocessor define Py_Debug is now correctly propagated to PySide2
sources, which fixes previous crashes in debug builds.
This affects only Linux and macOS builds. There is a subsequent change
for making it work for Windows builds.
All in all, this now allows proper mixing of debug / release versions
of the Python interpreter with debug / release versions of PySide2 on
Linux and macOS.
Task-number: PYSIDE-508
Change-Id: I88a05c3ada0fb32c7c29bdb86d7a2c15acc963b8
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
|
|
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.
|
