D8780: Try `llvm-config` to find `libclang`

[Shaheed Haque]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20171129/4e0bca82/attachment.html>