Community
Participate
Working Groups
Created attachment 176883 [details] Sample project with build log CQ:WIND00222792 Build ID: CDT 6.0.2 (Galileo) as well as CDT 7.0 (Helios) When user-defined Makefiles use drive-relative paths on Windows like this: cd /d X:\myproject gcc -o file.o -I/myproject/h -DFOO -c /myproject/file.c the path "/myproject/file.c" is not associated with a file X:/myproject/file.c residing in the CDT project being built (assuming that the project files are on drive X:), so the entire compile command is ignored. This is a major problem when the "Index source files not included in the build" Preference is turned off, because none of the files in the project will be indexed. Turning on the "Index source files not included in the build" Preference is a Workaround, but even so the include paths and preprocessor symbols are not discovered for any of the source files built with a drive-relative path. As a result, scanner discovery is practically unusable. Since the "/myproject/file.c" is a valid path notation on plain Windows which every compiler understands, the scanner discovery should also deal with this properly. Note that this is independent of using Cygwin or Mingw, these are plain Windows paths. Attached is a sample project with part of a real-world build log: 1. Extract attached zip somewhere, e.g. D:\tmp\DriveX 2. subst X: D:\tmp\DriveX 3. Import project from X:\ into Workspace 4. Project Properties > C/C++ Build > Discovery: Load X:\build1.log 5. Open /DiscoveryTest/kernel/bsp/common/src/commonSysUtils.c in Editor --> Note that no macros have been discovered. 6. Load X:\build2.log --> Now, all includes and macros have been discovered. --> The only diff between build1.log and build2.log is that the source file is now specified with a drive letter (X:/kernel/...) This is also loosely related to bug 234703.
I should add that I have seen drive-relative paths to be quite popular with Makefiles and ClearCase, since each ClearCase view uses a unique drive letter. Using drive-relative paths allows the build to use absolute paths but still be independent of the ClearCase view being used - similar like on UNIX. So this is an important issue to address.
I should also add that once the problem with the source file is fixed, include paths are properly associated although they use the drive-relative notation ("/kernel" is associated with "X:/kernel" automatically, when "X:/kernel" exists physically). So it looks like with a small fix, a big problem can be addressed.
Committed a fix to 7.0.1 and HEAD (8.0). Please, verify if it works for you.
*** cdt cvs genie on behalf of agvozdev *** bug 323011: [Scanner Discovery] Source files with drive-relative paths ("/foo/bar.c") are not discovered [*] GCCPerFileBOPConsoleParser.java 1.28 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.core/src/org/eclipse/cdt/make/internal/core/scannerconfig/gnu/GCCPerFileBOPConsoleParser.java?root=Tools_Project&r1=1.27&r2=1.28 [*] GCCPerFileBOPConsoleParser.java 1.27.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.core/src/org/eclipse/cdt/make/internal/core/scannerconfig/gnu/GCCPerFileBOPConsoleParser.java?root=Tools_Project&r1=1.27&r2=1.27.2.1
The fix works for sources that are physically located below the project root; but it (partially) fails for sources that are found through a Linked Resource. This is important, because the fix is especially relevant for ClearCase dynamic views. When a view spans multiple VOBs, it is impossible to create a project spanning all of those VOBs since the VOB root is not writable. Therefore, it is a very common pattern to have a project created on a local disk but access the Clearcase View through a Linked Resource. To reproduce this problematic scenario: 1. Extract the zip from attachment 176883 [details] somewhere, e.g. D:\tmp\DriveX 2. subst X: D:\tmp\DriveX 3. Create an empty project (type: Makefile Project) in Workspace e.g. D:\ws 4. Select Project, File > New > Folder : Advanced : Link to folder in FS --> Link "x" to "X:\" 5. Project Properties > C/C++ Build > Discovery: 5a) Load X:\build1.log --> only one Include is detected 5b) Load X:\build2.log --> again, only one Include is detected 5c) In build log, replace all includes with /kernel by X:/kernel --> many includes are detected I think the important point here is that when the build log reader knows that "X:/foo/bar" is the current directory, then any file reference like "/some/folder" should be interpreted as "X:/some/folder".
Created attachment 177210 [details] Sample project which links to source Import attached project to reproduce issues with linked sources: This project links to X:\ which needs to be set up as per the previous attachment. Importing "build1.log" or "build2.log" from X:\ fails discovering proper include paths (although macros are discovered OK). Importing "build3.log" from this project, which has the drive letter added everywhere, succeeds discovering include paths. Expected behavior: build1.log and build2.log should discover the same as build3.log.
(In reply to comment #5) > The fix works for sources that are physically located below the project root; > but it (partially) fails for sources that are found through a Linked Resource. Hey, there a scope creep right there! Somebody said in comment #2 > So it looks like with a small fix, a big problem can be addressed.
(In reply to comment #7) > Hey, there a scope creep right there! Somebody said in comment #2 Well, I admit that I had only tested without linked resources when I made comment #2; by only looking at the problem "from the outside", it did in fact appear that include paths were discovered properly. The scope creep had certainly not been intentional. Will it help if I open a new bug for the specific case of discovering behind linked resources, such that this one can be closed?
I'll take a look if it can be dealt with another easy fix. Thanks for detailed description of the problem, I am interested in those peculiar cases.
A fix for the second reported issue committed on HEAD (8.0) and 7.0.1. Feel free to scopecreep further but new bug report would be preferable.
*** cdt cvs genie on behalf of agvozdev *** bug 323011: [Scanner Discovery] Source files with drive-relative paths ("/foo/bar.c") are not discovered [*] ScannerInfoConsoleParserUtility.java 1.12 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.core/src/org/eclipse/cdt/make/internal/core/scannerconfig/gnu/ScannerInfoConsoleParserUtility.java?root=Tools_Project&r1=1.11&r2=1.12 [*] ScannerInfoConsoleParserUtility.java 1.11.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.core/src/org/eclipse/cdt/make/internal/core/scannerconfig/gnu/ScannerInfoConsoleParserUtility.java?root=Tools_Project&r1=1.11&r2=1.11.2.1 [*] ScannerInfoConsoleParserUtility.java 1.13 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.core/src/org/eclipse/cdt/make/internal/core/scannerconfig/gnu/ScannerInfoConsoleParserUtility.java?root=Tools_Project&r1=1.12&r2=1.13 [*] ScannerInfoConsoleParserUtility.java 1.11.2.2 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.core/src/org/eclipse/cdt/make/internal/core/scannerconfig/gnu/ScannerInfoConsoleParserUtility.java?root=Tools_Project&r1=1.11.2.1&r2=1.11.2.2
Created attachment 177313 [details] A better pach (against 6.0.2+ Stream) I did some more experiments (on the 6.0.2 branch), and found that files behind linked resources were still not properly associated. Part of this was due to bug 323498, but the other part was a problem with this fix. Attached is an alternative fix that works perfectly fine for me, and seems to run about 5 times faster than your fix in terms of Performance (I tried on an actual 1MB build log). I assume that the performance improvement is because with the fix, include paths that are already known need to be searched much less frequently. Note that this fix alone solves the problem for me in 6.0.2, so your other two changes don't seem to be needed. Could this be considered for all CDT Streams including 6.0.x ?
Reopen for considering my patch.
(In reply to comment #12) > Created an attachment (id=177313) > A better pach (against 6.0.2+ Stream) I reversed my changes and gave your patch a try. It is not working for me when testing against your sample project. In fact, the breakpoint on getAbsolutePath() never gets hit. Neither it worked for me on 6.0.X.
(In reply to comment #14) > In fact, the breakpoint on getAbsolutePath() never gets hit. This is very odd. Because when I look at your original changes from comment 4, which fixed the non-linkedResource-case: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.core/src/org/eclipse/cdt/make/internal/core/scannerconfig/gnu/GCCPerFileBOPConsoleParser.java?annotate=1.28&root=Tools_Project your change is in line 124, and getAbsolutePath() is called in line 102 so I would claim that it MUST be called. Perhaps a re-build while the target was running didn't proceed as expected?
Comment on attachment 177313 [details] A better pach (against 6.0.2+ Stream) The patch from comment 12 has not been applied so removing iplog flag.
(In reply to comment #16) > The patch from comment 12 has not been applied so removing iplog flag. Actually I will close this task (to attribute to 7.0.1/8.0) and open bug 345750 to consider the patch for future release. Martin, could you re-attach the patch there to keep iplog in order?
