Skip to content

415743 Add support for SIP v5 bindings

Amy spark requested to merge lsegovia/krita:work/amyspark/sip5-clean into master

This merge request proposes to add support for SIP v5 and above.

Unlike SIP v4, v5 and above rely on a PEP-0518 based tooling system to build bindings (usually distutils). v4, as our currently supported generator, is only a dummy tool -- it relies on the user to compile and link the bindings.

The first part of this MR adds a sip-generate tool; it's actually a copy-and-paste of the standard sip-build, that only generates the binding glue; this relies on a private, undocumented method of the sipbuild.Builder class. The cmake/modules directory also has now a pyproject.toml skeleton manifest, which is processed by the new add_sip_python_module_v5 macro. It works identically to the v4 macro, but targets the sip-generate tool. Compilation happens in the exact same was as we do with v4.

Key remarks about this:

  • All the data must be now injected in the skeleton manifest (as opposed to build flags in v4).
  • SIP v5 makes use of protected Qt methods; for this reason, it supplies a "protected-as-public" override, which I emulate in the add_sip_python_module_v5 macro.
  • Like v4, v5 also needs to be told the fully qualified name of the SIP package (e.g. import PyQt5.sip -- PyQt5.sip is the value). Otherwise, the native library will not find the package and the initialization will fail.
  • The initialization function changes, from "PyInit_pykrita" to "PyInit_krita" (the innermost module name). This has been macro'd for backwards compatibility.

The rest of the commits add the 3rdparty and packaging steps for each of our supported OSes. Additionally, macOS needs two additional fixes:

  • Deployment target versions were inconsistent, something that is checked by sipbuild prior to binding generation.
  • If I have signing disabled, it's pointless to check that everything is signed prior to notarization.

BUG: 415743

CCMAIL: kimageshop@kde.org

Test Plan

I need everyone with access to one of the 3 OSes (Linux AppImage, Windows MinGW, macOS) to try and package Krita with this MR.

I include the following test builds as proof of work: Windows, Linux, macOS.

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.
Edited by Amy spark

Merge request reports