Jan 29 2017
@arojas Is something comparable already done like that elsewhere in KDE? Like for documentation for example?
Jan 28 2017
@skelly not at all, 'make' and 'make install' should still install everything, the python_bindings target would be a subset of it.
@arojas Does that imply that 'make' alone should not build the bindings? I don't think that's generally desirable.
In order to allow clean splitting of the bindings in PKGBUILD-based distros, it would be great to have a make target to install the bindings, so one could simply do "make DESTDIR=foo install python_bindings". Would that be feasible?
Jan 15 2017
Jan 13 2017
I added https://commits.kde.org/extra-cmake-modules/29b9db8d67c67d4d1303e8dd9804f698fbaefbe1 in an attempt to resolve the issue of multiple packages installing the same __init__.py file.
Update on the installation directory issue. Instead of using 'dist-packages', the default is now 'site-packages', and packagers can now customize the install location for a package by passing
Jan 11 2017
Update on bug https://bugs.kde.org/show_bug.cgi?id=374801 , myself and @arojas fixed it. Packagers may want to cherry-pick the 8aa6843404f9c6faef66cb9c76358158eafc1af1 commit in ECM, and ed1b9ce2bb2a2e51410e0a1754a72c110010a6a0 if you encounter other problems to diagnose.
Jan 9 2017
If anyone else here can reproduce the issue in https://bugs.kde.org/show_bug.cgi?id=374801 I would appreciate if you could dig into it and figure out what the problem is.
@arojas I raised that issue in June: http://comments.gmane.org/gmane.comp.kde.distributions/92 and it came up in November: https://firstname.lastname@example.org/msg39376.html
Jan 6 2017
Another issue that needs to be dealt with, now that more frameworks ship bindings, is the multiple copies of PyKF5/__init__.py, which will make frameworks packages conflict with each other.
Jan 4 2017
I've massaged the code for finding libclang on FreeBSD a little; it now finds the library, but that's not a good way to do it because of the risk of mismatching libclang with the clang you're actually using (e.g. having llvm39 installed while using clang++38). So there would have to be more done to get this right:
- check $(CXX) is clang >= 3.8
- look for libclang in $(CXX) --print-search-dirs
Well, except that libclang doesn't live in the directory printed that way :| OTOH, llvm-config38 has the right information, but I'm not sure how to get from the clang version to the llvm-config version (in particular, system clang on 10.3 is clang 3.4, but there is no llvm-config34 or unversioned llvm-config). Getting to the right ClangConfig.cmake from the clang-version is tricksy, too.
Thanks for filing this.