Fwiw, I think that a specific version check may not be needed. The original
code I wrote, which I assume Steve may have simply carried forward in the
cmake ecm logic, DID have a version check but only because the python
bindings were newish circa libclang 3.8.
Afaik, there is no logic which is ver
lbeltrame added a comment.
+1, we have the same problem in openSUSE.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D5289
To: heikobecker, #frameworks, #build_system, skelly, kfunk
Cc: lbeltrame
heikobecker created this revision.
Restricted Application added projects: Frameworks, Build System.
REVISION 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 u
heikobecker created this revision.
Restricted Application added projects: Frameworks, Build System.
REVISION SUMMARY
...but use KDE_INSTALL_DATAROOTDIR instead.
REPOSITORY
R240 Extra CMake Modules
BRANCH
master
REVISION DETAIL
https://phabricator.kde.org/D5290
AFFECTED FILES
find-mod
heikobecker created this revision.
Restricted Application added projects: Frameworks, Build System.
REVISION SUMMARY
On non Debian-based systems libclang is mostly installed as
libclang.so., evading detection by
clang-${_LIBCLANG_FIND_VERSION}.0. Instead of specyfing and maintaing
a list o
