| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The proximate problem is that the Python Module generator cmake script
has started failing for people with Python 3.10, which a CMake backtrace
pointing into FindPythonModuleGeneration.cmake with an error of the form
"The max python version in PythonModuleGeneration must be updated."
At least one distro has addressed this by simply patching out modules
that happen to use this CMake module [1].
From what I can tell and the testing I've done, the cause is pretty
simple: The CMake script attempts to find the best Python 3 version by
starting from an impossible version and working backwards until it finds
a version that is installed.
As a sanity check, if the "impossible" version is actually present, it
aborts. But this appears to be just a sanity check, and not any sort of
guard against buggy version handling code later.
While the best fix is probably to start from a known *good* version and
move up until we stop finding better versions, there's problems here
(e.g. a user with 3.6 and 3.8 installed would fail to see 3.7 and so be
left with 3.6 as the "best" match), so I opted just to increase the max
version significantly, and improve the documentation as to what's
happening and whether it is safe to repeat the step again later.
[1]: https://bugs.gentoo.org/746866
|
|
CMake >= 3.0 supports bracket comments, and the reStructuredText
integration code in sphinx/ext/ecm.py already supports extracting
the docs from a bracket comment instead.
Editing documentation without leading line comment markers is more simple,
e,g. when reflowing text over lines.
With ECM meanwhile requiring CMake 3.5 now it is possible to switch
(and thus follow also the approach used by cmake itself).
NO_CHANGELOG
|
|
|
|
When PyQt5 is compiled with SIP 5, the sip files are installed to ${python-site-packages}/PyQt5/bindings, so search for them there too.
This doesn't add support for compiling KF5 bindings themselves with sip5, that requires more work.
Differential Revision: https://phabricator.kde.org/D25972
|
|
Summary:
The correct install directory is distro and arch specific, and should
match the configuration of the python installation the binding is
generated for. These directories can be queried using pythons
distutils.sysconfig.
When determining the install directory, it mimics the logic from
KDE_INSTALL_USE_QT_SYS_PATHS. When the python PREFIX is the same
as CMAKE_INSTALL_PREFIX, it defaults to using the path from
distutils.sysconfig, otherwise it keeps the current scheme, installing
below CMAKE_INSTALL_PREFIX.
The default behaviour can be changed by setting KDE_INSTALL_PYTHON{2,3}DIR
or by switching KDE_INSTALL_USE_PYTHON{2,3}_SYS_PATH ON or OFF.
Test Plan:
On a distro where sitearch is not below /usr/lib/pythonM.m/, but
/usr/lib64/pythonM.m/ (e.g. RH, SUSE 64bit), try to do:
cmake ..; make; install
Without the patch, the binding are installed into the wrong directory,
afterwards the correct path is used.
This should also yield the correct path on Debian and derivatives,
where dist-packages instead of site-packages is used (untested).
other test cases:
Keep current scheme: `cmake -DCMAKE_INSTALL_PREFIX=/opt ..`
Default to sys path: `cmake -DCMAKE_INSTALL_PREFIX=/usr ..`
Force sys path: `cmake -DCMAKE_INSTALL_PREFIX=/opt -DKDE_INSTALL_USE_PYTHON3_SYS_PATHS=ON ..`
Reviewers: #frameworks
Subscribers: bcooksley, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D15070
|
|
Summary:
The option is no longer used from any framework, and was always defaulting
to site-packages previously, as INSTALL_DIR_SUFFIX was empty.
Also see D15558, D15845.
Test Plan: build e.g kcoreaddons
Reviewers: #frameworks, apol, lbeltrame
Reviewed By: lbeltrame
Subscribers: lbeltrame, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D15867
|
|
PyQt>=5.11 is compiled with the 'PyQt5.sip' sipname by default. This causes a sipname mismatch with KF5 bindings and prevents them from loading:
To fix this, we compile KF5 bindings using the same sip flags (name and tags) that PyQt was compiled with. This ensures that we always use the correct sip name. We also stop setting the sip tags in FindPythonModuleGeneration.cmake to avoid duplication, and remove a (seemingly) unnecessary check for the Qt version that was forcing PyQt to be rebuilt for every patch Qt update.
Differential Revision: https://phabricator.kde.org/D15091
|
|
Summary:
Use of positional arguments is error prone, as e.g. switching order
of NAMESPACE and MODULENAME wont have the desired effect, as
the keywords are ignored for the first three arguments.
Parse all arguments with cmake_parse_arguments, and fix the documentation
(list supported arguments) and example (add TARGET keyword).
Test Plan: build bindings
Reviewers: #frameworks, dfaure
Reviewed By: dfaure
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D15559
|
|
|
|
Summary:
The generated C++ sources include <sip.h>, so it must be available.
Check for it in the version specific directories and fall back to
the default include directories.
Test Plan:
install python2-devel and python3-devel
install one of python{x}-sip-devel
bindings should be generated for the matching python version.
Reviewers: #frameworks, arojas
Reviewed By: arojas
Subscribers: arojas, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14915
|
|
Summary:
In case both python 2.7 and 3 are installed, but clang python bindings
are only installed for python 3, there will be no error message but
the self check will fail.
Check for clang bindings for both python2 and python3 (if installed),
and use the first one found to generate the sip bindings files.
Note, it is possible to e.g. use python2 to generate the sip binding
files (requires clang bindings), but generate bindings for python
2, 3, or both (requires matching python-devel and python-sip-devel
packages).
Test Plan:
install python3-clang bindings
install python2-clang bindings
or one of the above
the matching python version is used to run sip_generator.py
Reviewers: #frameworks, arojas
Reviewed By: arojas
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14914
|
|
Summary:
Keep the enum intact by emitting the class keyword in case the enum is
scoped.
Use the complete enum scope for parameter values, the enclosing scope is
only correct to use for unscoped enums.
The python Cursor.is_scoped_enum() method has been added with LLVM/Clang
version 5.0.
BUG: 397154
Test Plan: build kcoreaddons
Reviewers: #frameworks, mpyne
Reviewed By: mpyne
Subscribers: mpyne, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14908
|
|
Summary:
The canonical name is libclang.so, which seems to be available on all
distributions (RH, SUSE, Ubuntu, Debian, ...) while the symlinks with
version suffix (e.g. libclang-6.0) are specific to Debian and derivatives.
Keep the current checks, but fallback to the unversioned library name.
Test Plan:
on openSUSE TW/Leap:
run cmake
-> libclang is found
Reviewers: #frameworks, dfaure
Reviewed By: dfaure
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D14909
|
|
Explicitely set LIBRARY_OUTPUT_DIRECTORY for the python module
Differential Revision: https://phabricator.kde.org/D7677
CCMAIL: release-team@kde.org
|
|
Summary:
While my distro does have a versioned clang executable, it doesn't
have a versioned clang++ executable. The versioned executable is
still searched first, falling back to the unversioned one.
Reviewers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5291
|
|
Only one directory may provide the PyKF5 namespace, so if testing
KAuth, which depends on KCoreAddons, both have to be in the same
directory. That means that the KAuth tests can only be run
post-intallation which doesn't really cause problems.
|
|
The KConfig build creates two libraries and they should both be output
in the same place so that they can be tested together.
|
|
|
|
Packagers can execute this script with
cmake -D PYTHON_UMBRELLA_MODULE_FILE=/where/ever/PyKF5/__init__.py -P /path/to/ECM/find-modules/GeneratePythonBindingUmbrellaModule.cmake
Soon, this is likely to do more than create an empty file.
|
|
Use find_package to locate the executable.
|
|
The LLVM project has picked a new version scheme
http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
which means that major version numbers will be bumped more regularly,
the minor version will remain at zero, and the patch version will be
bumped. We will have to see how distros respond in terms of file
naming.
|
|
The suffix is used later to run the clang executable in order to
determine the built-in system includes.
|
|
The dist-packages directory which is currently hardcoded is unsuitable
to non-debian package creation. Set the directory to 'site-packages' by
default.
|
|
The generator expression here looks like it should work, but it does not
set the appropriate flags for compilation. It seems that the
CXX_STANDARD property is not yet populated at the time the generator
expression is evaluated (to be investigated later).
This came to light because users of Qt 5.7+ attempted to generate the
bindings, but they encountered errors. The step of using libclang to
parse the provided headers was actually failing, but that was not
noticed, perhaps because the logging infrastructure in sip_generator
does not emit it (to investigate later).
BUG: 374801
|
|
Summary: Cut-and-paste-o from the Python detection code.
Reviewers: #frameworks, skelly, apol
Reviewed By: apol
Subscribers: #buildsystem
Tags: #frameworks, #buildsystem
Differential Revision: https://phabricator.kde.org/D3952
|
|
|
|
This can be used by KF5 libraries to generate python 2 and 3 bindings.
|
