Community
Participate
Working Groups
I have a simple test case that includes a header file that isn't in the current project. The Makefile uses -isystem to specify the where-abouts of the header file. The compile is successful, but the indexer doesn't know where to find the missing header file. Files below. Test case fails with HEAD. It might fail with all 6.0 releases. I created an empty Std Makefile project and put the 2 files (asdf.c and Makefile) there. I placed the file: some.h in my home directory. You will have to change the location and set -isystem to some appropriate value for your system. asdf.c ------ #include <stdio.h> #include <stdlib.h> #include "some.h" int main(void) { int k = x; puts("Hello World"); /* prints Hello World */ return EXIT_SUCCESS; } Makefile -------- all: a.out a.out: asdf.c gcc -isystem /home/jjohnstn -O2 -o a.out asdf.c some.h ------ #define x 7
This is a configuration issue. Depending on how your project is configured you need to make sure that the scanner configuration is correctly determined and passed to the indexer. I don't know how your project configures the indexer, however I would think that it suffices to add the -isystem option to the arguments for the compiler inspection. (Project Properties - C/C++ Build - Discovery Options.
(In reply to comment #1) > This is a configuration issue. Depending on how your project is configured you > need to make sure that the scanner configuration is correctly determined and > passed to the indexer. > I don't know how your project configures the indexer, however I would think > that it suffices to add the -isystem option to the arguments for the compiler > inspection. (Project Properties - C/C++ Build - Discovery Options. This is a default Std Makefile project. When I go to Discovery Options, the options I am given are: Per Language vs Configuration-wide It is set to Per Language and has the following additional options: Automate discovery of paths and symbols Report path detection problems The name of the discovery profile: GCC per file scanner info profile (can't be changed) Enable build output discovery Load output from file (defaulted to empty) When I switch to Configuration-wide, the Discovery Profile switches to Managed Build System per project and the drop-down allows me to pick the C or C++ versions of this profile An additional box allows me to specify the scanner info compiler invocation arguments, but how do I tell the scanner to look for -isystem? I assume that the compiler invocation is how the scanner finds the default headers and defines so adding -isystem there would be pointless, correct?
(In reply to comment #2) > An additional box allows me to specify the scanner info compiler invocation > arguments, but how do I tell the scanner to look for -isystem? I assume that > the compiler invocation is how the scanner finds the default headers and > defines so adding -isystem there would be pointless, correct? You are right. If you have per file scanner discovery enabled it should parse your build output including -isystem option. I tried your example and it worked for me. I used Configuration-wide mode. Per-Language is disabled for Makefile project.
(In reply to comment #3) > (In reply to comment #2) > > An additional box allows me to specify the scanner info compiler invocation > > arguments, but how do I tell the scanner to look for -isystem? I assume that > > the compiler invocation is how the scanner finds the default headers and > > defines so adding -isystem there would be pointless, correct? > You are right. > > If you have per file scanner discovery enabled it should parse your build > output including -isystem option. I tried your example and it worked for me. I > used Configuration-wide mode. Per-Language is disabled for Makefile project. I tried changing over to the Configuration-wide mode and rebuilding, but it didn't work (the asdf.c file still complains about some.h), however, I noticed that I am currently using the checked out sources from CDT 6_0_1 due to a compilation issue with my own plugin. By any chance was this fixed in 6.0.2?
There were some changes but not likely affecting this particular problem. -isystem handling has been there for ages. Does plain -I gets parsed for you? Do you get anything in properties Paths&Symbols?
(In reply to comment #5) > There were some changes but not likely affecting this particular problem. > -isystem handling has been there for ages. Does plain -I gets parsed for you? > Do you get anything in properties Paths&Symbols? Yes, I see a combination of system header locations from C++ followed by C. That might be because I tried switching to the C++ profile momentarily to see if it worked. Anyway, -I statements have been working fine. I have another project that replaces the system header files like stdio.h. It uses the same Discovery profile and was finding the -I headers fine, but not the -isystem header location. When stdio.h is clicked on, it shows up from /usr/include, not the local build directory. A header file that is generated in the -isystem location that is not also a system header is found in the source tree (i.e. it's pregenerated state). That is why I tried to do a straight Std Makefile project to see if it got it right, but no luck thus far. It is encouraging that you have managed to get it to work with your system.
I cab also confirm that isystem is not parsed correctly with build id 20100617-1415 and CDT 7.0.0.
Still happens with. Version: 8.0.0.201106081058 Build id: 201106081058 It would be really nice to get this behavior for the isystem options.
This still happens on Juno.
Created attachment 222526 [details] Patch for GCC parser to include -isystem This patch probably fixes the issue. I have added another branch in the token processing for the GCC console parser comparable to the -I branch and modified for -isystem. I couldn't find out in a reasonable time how to install a patched plugin version correctly so that it loads without exception. So the patch is basically untested but the parsing code was easy to understand. So I expect no major issues with the approach.
(In reply to comment #10) > I couldn't find out in a reasonable time how to install a patched plugin > version correctly so that it loads without exception. So the patch is > basically untested but the parsing code was easy to understand. So I expect > no major issues with the approach. Hi Johannes. It's pretty easy to build a working CDT zip now, then you can update to that. Assuming you already cloned the CDT git repo and applied your change: 1. Install Maven if not already installed (mvn command) 2. cd to the cdt repo (the top folter that contains a pom.xml file) 3. Run "mvn package" 4. If the build is succesful, the zip will be in org.eclipse.cdt/releng/org.eclipse.cdt.repo/target/org.eclipse.cdt.repo.zip 5. Go to Install new software and point to the zip
(In reply to comment #11) > Hi Johannes. It's pretty easy to build a working CDT zip now, then you can > update to that. Assuming you already cloned the CDT git repo and applied > your change: > > 1. Install Maven if not already installed (mvn command) > 2. cd to the cdt repo (the top folter that contains a pom.xml file) > 3. Run "mvn package" > 4. If the build is succesful, the zip will be in > org.eclipse.cdt/releng/org.eclipse.cdt.repo/target/org.eclipse.cdt.repo.zip > 5. Go to Install new software and point to the zip Actually I was able to create a new zip, but I couldn't convince my working eclipse installation to load it and couldn't find a relevant error message or warning.
(In reply to comment #12) > (In reply to comment #11) > > Hi Johannes. It's pretty easy to build a working CDT zip now, then you can > > update to that. Assuming you already cloned the CDT git repo and applied > > your change: > > > > 1. Install Maven if not already installed (mvn command) > > 2. cd to the cdt repo (the top folter that contains a pom.xml file) > > 3. Run "mvn package" > > 4. If the build is succesful, the zip will be in > > org.eclipse.cdt/releng/org.eclipse.cdt.repo/target/org.eclipse.cdt.repo.zip > > 5. Go to Install new software and point to the zip > > Actually I was able to create a new zip, but I couldn't convince my working > eclipse installation to load it and couldn't find a relevant error message > or warning. How did you create the zip? Doing it with the maven build will create a regular p2 update site and it should give you error messages when you try to update to it in Install new software.
(In reply to comment #13) > How did you create the zip? Doing it with the maven build will create a > regular p2 update site and it should give you error messages when you try to > update to it in Install new software. I used some old instructions without maven from the wiki. Maybe I have time to retry this with maven. Do you see any obvious problems with the patch?
(In reply to comment #14) > Do you see any obvious problems with the patch? I have never used -isystem so I'll need some time to check it out and test. But it would be great to know whether or not it solves your problem.
I found some time to continue on this. Are there instructions anywhere how to compile CDT with maven? mvn install worked without errors but I cannot find any update site?
(In reply to comment #16) > I found some time to continue on this. Are there instructions anywhere how > to compile CDT with maven? mvn install worked without errors but I cannot > find any update site? I don't think there are instructions anywhere. I'll eventually create a wiki page for that but it'll probably be a copy/paste of comment 11 :p If the build was successful you should see where the zip ended up: Building zip: F:\dev\git\org.eclipse.cdt\releng\org.eclipse.cdt.repo\target\org.eclipse.cdt.repo.zip ------------------------------------------------------------------------ Reactor Summary: CDT Parent ........................................ SUCCESS [0.063s] ... That's the zip I use in Install New Software, Add, Archive...
Is there a chance, that proposed patch will be in next release?
Nobody cares? It's sad!
See bug 394959.
