shaheed added inline comments.
INLINE COMMENTS
> turbov wrote in FindPythonModuleGeneration.cmake:217
> As for me, I would remove whole this part of "brute forcing" available clang
> version. I can't see how it could work w/o additional hints due a location
> of `libclang` is not a standard directory (typically `/usr/lib/llvm-X.Y/`)
> and no `HINTS` given to `find_library`...
>
> Also this code is really lack of flexibility: what if I have few versions of
> `clang`, but want to use only particular one... (which is not a newest one)??
> -- Nowadays, this scenario not handled at all...
>
> Instead, I propose to be not so aggressive:
>
> - If a user has `clang` installed, let's ask the version of it (`clang
> --version`), then "guess" a library dir
> - if nothing found, then OK... just skip the generation of SIP files...
> - If a user has some private installation of Clang (possibly built somewhere
> in `/home/john/work/tools/clang/...`) and really want to build Python
> bindings, let's give him an option to provide a libdir via CMake CLI (like
> `-DGPB_LIBCLANG_PATH=...`)
> - If a user wants a particular version, he always can set a hint variable to
> the desired path...
I have found a new, potentially less horrid, approach to finding libclang. It
turns out that the Python bindings expose some APIs which I had not noticed
before, meaning that - AFAICS - the bindings are more or less able to find the
library they need by themselves. Also the relevant support code appears to be
platform sensitive, so stands some chance of working on Macs and Windows.
You may wonder why, given this, we need to do anything at all...I can only
guess the authors wanted to give users the ability to override the default
library choice. The resulting Python code can be completely self-contained,
with the main reason to need CMake support being to support any such override:
from clang.cindex import Config
if args.libclang:
Config.set_library_file(args.libclang)
lib = Config().lib
However, there is a secondary reason too: Python3 support. The problem is that
the even though upstream has, as of libclang-5.0 shipped Python3 support, the
distros mostly have not yet picked this up (I've filed requests for both Debian
and Ubuntu). Until then, the pPython bindings are only usable from Python2. I
have a FindLibClang.cmake which does the necessary work here:
https://bitbucket.org/ShaheedHaque/cppyy-backend/commits/d585e46cf60a866b0d6649960a53a2bd40af626b?at=feature_cmake_macros#chg-cling/python/cppyy_backend/cmake/FindLibClang.cmake
Good luck.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D8780
To: turbov
Cc: cgiboudeaux, shaheed, #frameworks, #build_system
