| Summary: | after i installed clang 7.0.1, variable hint is not working | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | clydelee |
| Component: | Language Support: CPP (Clang-based) | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | arojas, mail, rjvbertin |
| Priority: | NOR | ||
| Version First Reported In: | 5.3.1 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| URL: | https://phabricator.kde.org/D17858 | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
clydelee
2018-12-28 05:33:45 UTC
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 ... |