Open
Conversation
By checking if an enum member has already been cached it is not required anymore to skip it if is a QFlags. Additionally, the wrapping of QFlags can now be done by using only Q_FLAGS without having a corresponding Q_ENUMS. Cherry-picked from commontk/PythonQt@86068fd
jamesobutler
force-pushed
the
add-cmake-build-system
branch
10 times, most recently
from
da92bd6 to
d716b30
Compare
… commontk/PythonQt fork This commit partially reverts r431 (which removed unsupported files and added documentation) and consolidates consolidates historical changes developed in the `commontk/PythonQt` fork between 2011 and 2021. Summary: * Qt 5support: * Added initial and ongoing support for Qt5, including modules like `PrintSupport`, `QuickWidgets`, `Multimedia`, and `OpenGL`. * Removed Qt4 support; fixed CMake logic for building across Qt 5.3–5.9. * Introduced `pythonqt_wrap_cpp` macro and cleaned up legacy Qt macros. * Build system enhancements: * Re-enabled and expanded CMake support with configurable install paths and testing. * Removed use of `INSTALL_NAME_DIR` to support relocatable installs. * Addressed build issues across toolchains (e.g., MSVC `/bigobj` workaround, debug mode fixes). * Added missing source files and build flags. * Code quality and compatibility: * Replaced deprecated/legacy constructs (e.g., use of `nullptr`, fixed property aliasing with `name` → `objectName`). * Added support for 511 wrappers. * Resolved warnings and linkage issues with optional build flags (e.g., `PythonQt_Wrap_Qtcore`). * Testing and cleanup: * Added cleanup/finalization unit tests. * Ensured test code compiles cleanly when wrapping is partially disabled. (cherry picked from commit MeVisLab/pythonqt@93c546e) Co-authored-by: Florian Link <5535644+florianlink@users.noreply.github.com> Co-authored-by: Matthew Woehlke <matthew.woehlke@kitware.com> Co-authored-by: Max Smolens <max.smolens@kitware.com> Co-authored-by: Pat Marion <james.patrick.marion@gmail.com> Co-authored-by: Francois Budin <francois.budin@kitware.com> Co-authored-by: Christoph Willing <chris.willing@linux.com> Co-authored-by: Stefan Dinkelacker <s.dinkelacker@dkfz-heidelberg.de> Co-authored-by: Sylvain Bernhardt <sylvain.bernhardt@smith-nephew.com>
PythonQt_QtBindings.cpp and PythonQt_QtBindings.h were copied over from the generated_cpp_511 directory.
This changes the `PYTHONQT_SUPPORT_NAME_PROPERTY` definition from a global `add_definition` to a target-specific compile definition and adds the CMake option `PythonQt_SUPPORT_NAME_PROPERTY` set to ON by default.
…perty This converts the `PYTHONQT_USE_RELEASE_PYTHON_FALLBACK` definition from a global add_definition to a target-specific compile definition and adds the CMake option `PythonQt_USE_RELEASE_PYTHON_FALLBACK` set to ON by default.
This changes the include directories from global include_directories to target-specific target_include_directories. This improves the encapsulation and modularity of the build.
This changes the PYTHONQT_DEBUG definition from a global add_definition to a target-specific compile definition.
This simplifies Qt5 integration by using Qt5 imported targets instead of manually including directories and definitions.
…ated_cpp_5.15 This removes obsolete support for generated_cpp configurations other than 5.15.
The FindPythonLib CMake module is deprecated since CMake 3.12 and starting with CMake 3.27 the module is not provided unless CMP0148 is set to OLD. To integrate PythonQt in other project, the CMake variables `Python3_LIBRARY` and `Python3_INCLUDE_DIR` may be set instead of `PYTHON_LIBRARY`, `PYTHON_INCLUDE_DIR` and `PYTHON_INCLUDE_DIR2`. Options `Python3_ROOT_DIR`, `Python3_LIBRARY_DEBUG` and `Python3_LIBRARY_RELEASE` may also be set. Co-authored-by: Hans Johnson <hans-johnson@uiowa.edu>
Introduce `PythonQtConfigure.h` to derive `PYTHONQT_USE_RELEASE_PYTHON_FALLBACK` from the CMake option `PythonQt_USE_RELEASE_PYTHON_FALLBACK`. Export build-tree binary include dir and install the configured header so `#include <PythonQtConfigure.h>` works for both build and install trees. Stop requiring downstreams to set the macro via compile definitions; users can still override by predefining `PYTHONQT_USE_RELEASE_PYTHON_FALLBACK`.
make PythonQt_QtAll export macro treat both PYTHONQT_QTALL_EXPORTS and PYTHONQT_EXPORTS as build context Co-authored-by: James Butler <james.butler@revvity.com>
- Leverages automatic execution of MOC and RCC. - Removes obsolete install rules for `build_*.txt` and `typesystem_*.xml`. - Uses "usage requirements" and aligns source lists with `parser/rxx.pro`, `simplecpp/simplecpp.pri`, `generator.pri`, and `generator.pro`.
This removes the use of version-specific Qt variable like `Qt5Core_PRIVATE_INCLUDE_DIRS` and instead relies on CMake’s imported targets for private headers.
- Add configurable Qt major version (5 or 6) with sensible default
(Qt6 if Qt6_DIR is defined, otherwise Qt5).
- Require Qt >= 5.15.0 or Qt >= 6.9.0.
- Switch component discovery and linking to `Qt${MAJOR}::...` targets.
- Define QT_VERSION_MAJOR/MINOR from the found package.
- Make pre-generated wrappers default only for Qt5 (generated_cpp_515);
for Qt6, default to unset (wrappers must be generated).
This simplifies the mapping of Qt wrapped libraries to their components by removing the redundant version-specific prefix 'qt5' from variable names.
This updates the mapping of Qt wrapped libraries to components to support Qt6. Additional dependencies for certain components are included when PythonQt_QT_VERSION is 6.
Partially reverts dd82ba4b ("[commontk] cmake: Simplify build-system
leveraging AUTOMOC capability", 2025-10-23) to fix a build error
reported when AUTOMOC merges all `moc_*.cpp` into one Translation Unit
(TU) (`<target>_autogen/mocs_compilation*.cpp`).
This change includes:
- Reverting to manual specification of moc sources.
- Disabling AUTOMOC for specified sources to avoid QMetaTypeId
specialization conflicts.
This fixes the following error:
```
In file included from /path/to/Support/Qt/6.9.1/gcc_64/include/QtCore/qvariant.h:10,
from /path/to/Support/Qt/6.9.1/gcc_64/include/QtCore/qmetaobject.h:10,
from /path/to/Support/Qt/6.9.1/gcc_64/include/QtCore/QMetaMethod:1,
from /path/to/Projects/PythonQt-CTK/src/PythonQtUtils.h:49,
from /path/to/Projects/PythonQt-CTK/src/PythonQt.h:46,
from /path/to/Projects/PythonQt-CTK-cmake-Qt6-Release/PythonQt_autogen/CRAGYDUSE3/../../../CTK-Qt6-build/PythonQtGenerator-output-6.9.1/generated_cpp/com_trolltech_qt_core/com_trolltech_qt_core0.h:1,
from /path/to/Projects/PythonQt-CTK-cmake-Qt6-Release/PythonQt_autogen/CRAGYDUSE3/moc_com_trolltech_qt_core0.cpp:9,
from /path/to/Projects/PythonQt-CTK-cmake-Qt6-Release/PythonQt_autogen/mocs_compilation.cpp:2:
/path/to/Support/Qt/6.9.1/gcc_64/include/QtPrintSupport/qprintengine.h:12:1: error: specialization of ‘QMetaTypeId<QMarginsF>’ after instantiation
12 | Q_DECLARE_METATYPE(QMarginsF)
| ^~~~~~~~~~~~~~~~~~
/path/to/Support/Qt/6.9.1/gcc_64/include/QtPrintSupport/qprintengine.h:12:1: error: redefinition of ‘struct QMetaTypeId<QMarginsF>’
/path/to/Support/Qt/6.9.1/gcc_64/include/QtCore/qmetatype.h:1232:8: note: previous definition of ‘struct QMetaTypeId<QMarginsF>’
```
This changes the minimum required Qt6 version from 6.9.0 to 6.4.0 to ensure compatibility with Ubuntu 24.04, which ships with Qt 6.4.2.
Since XmlPatterns was removed in Qt 6, it should not be considered. See https://doc.qt.io/qt-6/whatsnew60.html#removed-modules-in-qt-6-0
jamesobutler
force-pushed
the
add-cmake-build-system
branch
from
d716b30 to
436435c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is an effort previously discussed to bring in the CMake build system for modern cross compilation of C++ libraries. This PR includes the CMake build system as of https://github.com/commontk/PythonQt/tree/patched-v4.0.1-2026-03-16-5cd9b581f. The CommonTK organization is used by applications such as 3D Slicer and MITK. Using CMake to build PythonQt has been utilized successfully by 3D Slicer for well over a decade. Integration of this work back to the upstream has taken a long time due to multiple factors including MeVisLab's PythonQt source repository not on GitHub and 3D Slicer maintaining a series of patches that had not been contributed back to the upstream. Both situations have changed where PythonQt is on GitHub and the long list of patches were contributed to the upstream in the fall of 2025.
A large majority of this CMake work is due to the fantastic work by @jcfr who also worked to contribute the patches back to this upstream repo. Late last year JC made a job move to Nvidia and therefore contributions to 3D Slicer and the ecosystem of supporting open-source libraries has been limited. I submit this PR to keep this work going to bring the CommonTK fork of PythonQt back in sync with the MeVisLab PythonQt upstream.
I provide all the commits here for the CMake development for historic reference, but maintainers could consider squashing of commits for less noise.
I have created a new GitHub actions workflow as part of testing the CMake build system similar to the existing CI infrastructure. This PR doesn't currently remove the existing build system, though maintainers here could consider a replacement based on stabilization here and then avoid the complexity of maintaining 2 build systems.