| skelly | |
| kfunk |
| Frameworks | |
| Build System |
On non Debian-based systems libclang is mostly installed as
libclang.so.<version>, evading detection by
clang-${_LIBCLANG_FIND_VERSION}.0. Instead of specyfing and maintaing
a list of library names I imported FindClang from KDevelop, which
finds the correct library here and, one would assume, also works on
Debian and distros based on it.
I didn't use ClangConfig.cmake from upstream because it doesn't allow
discovery of a certain version.
Successfully built kconfig with Python bindings
| No Linters Available |
| No Unit Test Coverage |
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 version-specifc in the code. (Otoh, I
have not specifically tested for this).
I'm certainly open to using ClangConfig.cmake and would even prefer it, but I guess I'll wait for feedback from Steve about the version requirement.
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.
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.)
My preference would be to use the ClangConfig.cmake instead of introducing these new files.