https://bugs.kde.org/show_bug.cgi?id=415743

amyspark <a...@amyspark.me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Latest Commit|                            |https://invent.kde.org/grap
                   |                            |hics/krita/commit/5bb4874ad
                   |                            |04b771a0fec12827de748780b5b
                   |                            |395b
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from amyspark <a...@amyspark.me> ---
Git commit 5bb4874ad04b771a0fec12827de748780b5b395b by L. E. Segovia.
Committed on 23/05/2021 at 02:34.
Pushed by lsegovia into branch 'master'.

Add support for SIP v5 bindings

SIP 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.

This commit adds support for SIP v5.

- I've added a "sip-generate" tool, that differs from the standard
sip-build in that it only generates the binding glue; this relies on a
private, undocumented method of the sipbuild.Builder class.

- The cmake/modules directory now has 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:

- 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.

CCMAIL: kimages...@kde.org

M  +5    -0    cmake/modules/FindPyQt5.cmake
M  +5    -0    cmake/modules/FindPyQt5.py
M  +3    -3    cmake/modules/FindSIP.cmake
M  +7    -4    cmake/modules/FindSIP.py
M  +103  -6    cmake/modules/SIPMacros.cmake
A  +15   -0    cmake/modules/pyproject.toml.in
A  +24   -0    cmake/modules/sip-generate.py
M  +2    -3    plugins/extensions/pykrita/plugin/PykritaModule.cpp
M  +9    -1    plugins/extensions/pykrita/plugin/PykritaModule.h
M  +3    -0    plugins/extensions/pykrita/plugin/config.h.cmake
M  +3    -2    plugins/extensions/pykrita/plugin/utilities.cpp
M  +33   -25   plugins/extensions/pykrita/sip/CMakeLists.txt

https://invent.kde.org/graphics/krita/commit/5bb4874ad04b771a0fec12827de748780b5b395b

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to