SUMMARY after i am installed clang 7.0.1, variable hint is not working STEPS TO REPRODUCE 1. install llvm, clang 7.0.1 2. run kdevelop, and open c++ project 3. mouse over on variable OBSERVED RESULT nothing is... EXPECTED RESULT variable hit window is showed SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.1 ADDITIONAL INFORMATION
Did you rebuild kdevelop against clang 7.0.1?
I now recompiled kdevelop. hint window is working. thx! if i will install clang 7.0.2 at future, should i recompile kdevelop ?
Yes. KDevelop's build process is conditional in many places on the Clang version, and related properties such as file paths, with the result being compiled into the resulting binary. Changing the version of Clang, Qt, CPython or any other build-time dependency without a rebuild is not supported and very likely to cause problems. This is true for the majority of software, not only KDevelop.
Time and practice will tell but I think you will find that clang 7.0.2 doesn't require a rebuild, as long as it is installed in the same location as 7.0.1 . Just like upgrading Qt usually doesn't require a rebuild as long as the upgrade doesn't also change the install location. Downgrading or upgrading to a new major version is more likely to require a rebuild.
Thx for relpies ^^.
On Arch at least, the path to Clang's builtin headers includes the version: `/usr/lib/clang/7.0.1/include/cpuid.h` Since having the correct path is necessary for kdev-clang to function, and the path is detected in FindClang.cmake at build-time, installing 7.0.2 without a rebuild WILL break KDevelop when this is the case. Again: Changing dependency versions without a rebuild is NOT supported. If you cut corners and it still seems to work, you get to keep both pieces whenever it breaks. (ccache helps a lot for rebuilding things efficiently)
I would have expected that kdev-clang depends on libclang to obtain the paths to any headerfiles it needs at runtime. Indeed it isn't, and I can only see that as a design flaw that more or less obliges you to build it against a private libclang copy. Question is still open in who's design flaw it is, kdev-clang's or libclang's ...