Community
Participate
Working Groups
Created attachment 104697 [details] Patch for changing the intel error parser file locating behaviour Build ID: I20080530-1730 Steps To Reproduce: 1. (remember to add the error parser for Intel Compilers to the project) 2. Compile something that produces error/warning/info messages on the form "fortcom: Info: my_file.f90, line 156: This variable has not been used. [VARNAME]". More information: Because the error parser is unable to extract the correct path, annotations in the editor fail to show up, and double clicking the entry in the "Problems" view does not open the source code in the editor. Note, that if the error parser encounters text on this form: "my_file.f90(751): (col. 4) remark: LOOP WAS VECTORIZED." there is no problem. It gets annotated properly. I had a look at the error parser code, and it appears that the two sectins of code that parse these two different kinds of feedback call different methods in order to determine the file name. The one that works for me is eoParser.findFileName(filestr). Then one that does not is eoParser.findFilePath(filestr). After applying the attached patch, I have no problems. I don't know if it is a sensible way to handle things on different systems, though.
Hello Erlend. I tried to reproduce the behavior you reported, but it seems to work o.k. for me. I created a simple helloworld program with a few unused integer variables added. I enabled the warn unused option and built the project. I'm getting the correct annotations in the 'Problems' view and double clicking on an entry goes to the correct line in the editor view. I also get the correct 'Path' information. Is there something more to the steps you take before you encounter the problem? Thanks, Bill Hilliard
I don't think I do anything fancy in the Eclipse setup, but I reckon the following are important factors that I didn't think to include in the original bug report: 1. I usually keep source code at several directory levels, within a src folder below the project root. Typically, programs go in src/bin/, and library code in src/lib/lib1/, src/lib/lib2/ and so on. 2. I generate makefiles using automake. 3. I typically build outside the source tree, in subdirectories build/debug/ and build/release/. So the base directory of the build is not the same as the project root. This means that the file paths reported from make typically start with '../../../' and so on, which I recon is where the problems begin. I tried doing what you did, and, yes, it does work OK in the single-directory "hello world" case. So the relative paths are probably the problem.
I could supply an example project zip file in which the bug appears for me, if such a thing is wanted..?
I've checked in the change you suggested to fix this behavior. Thanks, Bill
