Community
Participate
Working Groups
I have described the problem I have on Eclipse's forum, but it seems it's not a good channel, so here I am. I have a project using Makefile and "Cross GCC" (targeted at ARM bare-metal microcontrollers). I always configure CDT GCC Build Output Parser the same way - the compiler command pattern is ".*((gcc)|([gc]\+\+)|(clang))" - I just add "any" prefix, as the compiler is arm-none-eabi-gcc etc. This works fine as long as I DISABLE the option (enabled by default) to use heuristics to resolve paths. With this option disabled the scanner keeps the paths "relative", so if I pass "-Ifolder/subfolder" to the compiler I get exactly "folder/subfolder" in the discovered entries. However - when I leave this option enabled (or don't disable it), then the scanner goes crazy... It the workpace (with the project) is located on D:/workspace/ the scanner's heuristics resolve these relative paths to "C:/workspace/project/folder/subfolder" - that's the other disk, and no part of that path exists (apart from "C:/" of course)... So if I create a workspace on C:/new_workspace/ and try the same thing, scanner thinks the include path is on "D:/new_workspace/project/folder/subfolder" - again - wrong disk, no part of this path exists... Eclipse even knows that this path is wrong, because if I review the entries the paths have an exclamation mark in a yellow triangle on the icon, and - when selected - there's a info below the list that "The selected folder foes not exist or not accessible.". The funny thing is that if the paths are complicated, so with "..", going up and down a few levels - parser gets all of that right, only the disk is wrong. I'm pretty sure it worked some time ago, but now I just cannot make it work again - the workspace have been created from scratch several times, so that's not some old/wrong/incompatible setting. Any help appreciated!
I had some time to investigate that a bit more. I've narrowed down the problem to a situation when following conditions are met (both at the same time): 1. the workspace is on a different drive than Eclipse, 2. include path is not "in" or "below" the folder of the source file. Ad.1. Nothing much to explain - Eclipse on C:\, workspace on D:\ -> problem, Elipse on C:\, workspace on C:\ -> works fine. Ad.2. If the heuristics are enabled, includes like these are parsed and "guessed" correctly: -Isth -I./sth -Imany/levels/down However these are parsed to be on a wrong ("opposite") drive: -I../above -I../above/sth/else -I.
Hmm, wrong drive sounds like some path (IPath) is getting constructed but without the device part (IPath.setDevice). It's just a guess though. I'll give it a try when I have access to Windows again. Does the same problem happen with the MinGW toolchain? I think the problem might be around AbstractLanguageSettingsOutputScanner.getMappedRootURI if you feel like debugging this yourself. https://wiki.eclipse.org/Getting_started_with_CDT_development
Yes, the same happens when using MinGW toolchain. I will attach an extremely simple test case, which is a modified "Hello World" example created by Eclipse. I've changed only these: - moved all files to a "source" subfolder - changed build directory to "source" subfolder - added a "header" subfolder, added it to include path via Makefile - to make it more useful as an uploaded evidence, I've checked "store entries in project settings folder ..." in CDT GCC Build Output Parser options. Discovered path: C:/Elektronika/PC/projects/test/header Real path: D:/Elektronika/PC/projects/test/header Eclipse's location: c:\ARM\eclipse-cpp-kepler-SR1-win32-x86_64\eclipse\ Build output: > make all > g++ -O2 -g -Wall -fmessage-length=0 -I../header -c -o test.o test.cpp > g++ -o test.exe test.o As for debugging, I'm not sure it's a good idea (; I don't really know much about Java, I'm more into embedded C/C++... If any info I can provide via debugging might help, I could give it a try...
Created attachment 239965 [details] test project which shows the problem, see comment #3 7-zip
Thanks! I can reproduce the bug now.
Particularly, the problem seems to be in the following line inside org.eclipse.cdt.managedbuilder.language.settings.providers.AbstractLanguageSettingsOutputScanner.getBuildDirURI(URI): buildDirURI = efsProvider.append(mappedRootURI, cwdPath); In this case, the mappedRootURI is empty ("file:/"), and the cwdPath indeed is an absolute path to the container of the detected file. Assembling such an URI with such a path results in an invalid URI, and later on I suspect the default device is used instead.
CQ:WIND00-WB4-2995
