Version: 3.3.1 (using KDE KDE 3.5.1) Installed from: SuSE RPMs Compiler: gcc version 4.0.2 20050901 (prerelease) (SUSE Linux) OS: Linux If I build my project and the C++ compiler reports a number of errors, then the "errors" tab of the "problems" output view remains empty nevertheless.
The "Problems" view only reports syntax errors the parser has discovered. Commonly, it will only contain entries from the active (visible) file. There are in other words a large set of cases where the compiler may well discover problems that the syntax problem reporter hasn't reported. It's not possible to derive from your description if what you have observed is one of these cases. In any case, the parser is non-perfect, and there are likely a number of cases where it doesn't report a problem that exists, or flags something as an error which isn't (common with macros).
I am new to kdevelop and couldn't find anything in the kdevelop manual on compiler error reporting and how you can easily jump to the source line of an error. So I had assumed that kdevelop resembles other IDEs like Eclipse or SourceNavigator where you can click or double-click on an error message line in a "problems" view (as in Eclipse) or directly on an error message line in the compiler message window (as in SourceNavigator) in order to jump to the erroneous source line. Isn't there a similar mechanism in kdevelop? Is it really necessary to open the respective source file and to scroll to the respective line number manually?
> Is it really necessary to open the respective source file > and to scroll to the respective line number manually? of course not! when you build your project, the "real" compiler errors (not the internal parser ones) appear in the "Messages" output view, and from there you can jump to any of the shown errors with a single click onto the error message.
I have tried this many times, since I have been convinced, of course, that this is what you could expect. But It worked only in some cases; in most cases there wasn't any reaction.
Please give more details otherwise we can not track it. The "messages" view should always jump to the correct line.
Issues with the error-jump feature of the 'Messages' view have been reported many times. The problems involve the buildsystem, the filesystem layout and the precense of symlinks in the project path and KMDI (if the Messages view is detached, clicking in it reportedly doesn't work, IIRC). So we're pretty far from the 'Problems' view by now, but no closer to understanding the problem.
I think I have now found out under which circumstances the error-jump feature fails, at least in our project context: Our project consists of several sub-projects, which reside in sub-directories of the workspace root directory and have their own makefiles. The entire project structure has also a global makefile, residing in the root directory. You can invoke "make" in the root directory as well as in the individual project-specific sub-directories. Every project P may depend on several other projects which are built before P is built. In this case the make utility outputs "entering/leaving directory ..." messages (which presumably are analysed by kdevelop). I suppose that the error-jump succeeds if and only if the error occurs in one of the directories mentioned in one of these "entering ..." directories, or if there aren't any "entering ..." directories and the error occurs in the only project directory involved. Or in other words: The error-jump fails if there are "entering ..." directories but the error occurs in the primary project belonging to the main makefile.
Yes, this sounds like a likely explanation of the problem. KDevelop attempts to follow those "entering/leaving" messages, as you say, and in the absense of them, it probably makes a mistake when it attempts to guess what directory the compiler is running in. It's hard to see how a foolproof solution would work, that works with all buildsystem setups out there.
> It's hard to see how a foolproof solution would work, that works with all > buildsystem setups out there. Ok, but I think a most obvious and better guess than now would be to just take the working directory where the original make started. (That would at least solve my problems with kdevelop!)
> Ok, but I think a most obvious and better guess than now would be to just > take the working directory where the original make started. (That would > at least solve my problems with kdevelop!) Sorry, that's only true if you have only one nested make-level. The general rule is to take the last directory that has been entered but not yet left as the current compile directory, where the initial working directory of the top-level make counts also as "entered" although there is no explicit "entering directory ..." message for this.
This feels like a dupe, but lets start with renaming it to something that matches its contents.
*** Bug 87838 has been marked as a duplicate of this bug. ***
*** Bug 81713 has been marked as a duplicate of this bug. ***
Yup, it's a dupe. *** This bug has been marked as a duplicate of 65541 ***