skelly added a comment.
My preference would be to use the ClangConfig.cmake instead of introducing
these new files.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D5289
To: heikobecker, #frameworks, #build_system, skelly, kfunk
Cc: rdieter, shaheed, kde-
heikobecker added a comment.
Ping? Not sure what to do with this, still would like to hear something from
@skelly. Or should I just go ahead and use ClangConfig.cmake (meaning dropping
the version requirement, I don't have any older clang versions around to easily
test it.)
REPOSITORY
R24
shaheed added a comment.
I did some negative testing, and from what I can see, 3.8 might well be OK
for the ECM fork. My version depends on 3.9 (for example, there are some
new constants defined by clang which I use), but I've no idea if this will
ever be merged.
REPOSITORY
R240 Extra
heikobecker added a comment.
In https://phabricator.kde.org/D5289#99625, @shaheed wrote:
> 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 che
shaheed added subscribers: kde-buildsystem, shaheed.
shaheed added a comment.
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
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
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
