Home » Language IDEs » C / C++ IDE (CDT) » Simple test case not finding include files(Include Files not found from User Settings Include Paths)
| Simple test case not finding include files [message #1781320] |
Tue, 06 February 2018 02:26  |
 Chad Farmer
Messages: 7
Registered: February 2018 |
Junior Member |
|
|
I'm trying to understand how the Eclipse project configuration and CDT C parser work.
To set up a simple test, I've disabled all Preprocessor Include Paths Providers except for "CDT User Setting Entries". To that I've added defines, include paths, include files, etc. In the attached png screenshot, the existence of my User Defined Include directories can be seen in Project Explorer under "Includes".
The "Search" tab shows the start of a much longer list of errors produced by "Index -> "Search for Unresolved Includes". The project is named "linux-bmc". I assure you that "linux-bmc/include" contains "linux/compiler.h" and "linux/string.h", etc.
In my mind, I've told the parser where to look for include files, and it is not finding them.
Can someone suggest the (probably obvious ) thing I'm doing wrong?
ps: when I say simple test, I'm talking about the number of options I'm setting, not the size of the project.
Version: Oxygen.2 Release (4.7.2)
Build id: 20171218-0600
Installed from eclipse-cpp-oxygen-2-linux-gtk-x86_64.tar.gz (sha512 verified)
|
|
| |
| Re: Simple test case not finding include files [message #1781494 is a reply to message #1781412] |
Wed, 07 February 2018 21:34  |
Chad Farmer
Messages: 7
Registered: February 2018 |
Junior Member |
|
|
Thanks for reading my message and replying. [I should have added my image to the body, rather than only as an attachment.] With respect to the original attachement, the Project Explorer pane "Includes" items are include directories in the configuration (this is different from the directory "includes").
In the Project Explorer pane, it is odd that include directories entered as "file system path" show subordinate directories and include files, but include directories within the Project do not show any subordinate detail. Its been a few days, but I believe it doesn't matter how the include directory is entered. CDT recognizes the path as being inside the project and doesn't show any detail.
Back to the problem
I don't understand why the indexer is not finding include files that are in configured include directories.
I deleted the project and created it again, this time specifying toolchain <none>. I un-selected the two other Providers, leaving only "CDT User Setting Entries". As before, I added all the include files, include directories, preprocessor macros, etc. When I clicked "Close and Apply", the indexer ran. After it finished, I noticed that I had forgotten to set source filters to eliminate non-arm architecture files under ./arch, ./arch/mach-<other>, and ./include/asm-<other>. I set the filters and the indexer ran (after sending an error report). In any case, Index -> Rebuild did not report another error.
I did project Index -> Search for unresolved includes. The results follow.
And before anyone asks, I do have the User Entries setup.
|
|
| | |
| Re: Simple test case not finding include files [message #1781632 is a reply to message #1781589] |
Fri, 09 February 2018 19:55 |
Chad Farmer
Messages: 7
Registered: February 2018 |
Junior Member |
|
|
Thanks, I need some help in debugging CDT.
Attached is the parser log file for misc.c. Note that arch/arm/boot/compressed/misc.c is just the first file parsed, so its warning is at the top of the "Search for unresolved includes" output.
Following is a summary of the attached file. From my naive perspective, the log file reports the correct include search paths and then fails to search them.
My Linux build has 22 string.h files, but there is only one "linux/string.h".
Build Configuration: Default
Context: file:/home/cfarmer/test/newsdk2/linux/arch/arm/boot/compressed/misc.c
C, {}
Versions in Index: 1
C: {}; 21 macros, 6 includes, 120 names;
Include Search Path (option -I):
/builds/fedora10/usr/lib/gcc/armv4-pp004-linux-uclibcgnueabi/4.3.2/include
/home/cfarmer/test/newsdk2/install_root_final/include/local/shared
Local Include Search Path (option -iquote):
/home/cfarmer/test/newsdk2/linux/include
/home/cfarmer/test/newsdk2/linux/arch/arm/include
/home/cfarmer/test/newsdk2/linux/arch/arm/mach-pilot3bulldc/include
Preincluded files (option -include):
/home/cfarmer/test/newsdk2/linux/include/linux/autoconf.h
/home/cfarmer/test/newsdk2/pp_features.h
Macro definitions (option -D):
KBUILD_BASENAME=KBUILD_STR(main)
KBUILD_MODNAME=KBUILD_STR(main)
. . .
Macro definitions (from files actually parsed):
arch_error(x)=
ARCH_HAS_DECOMP_WDOG=
Assert(cond,msg)=
Assert(cond,msg)={if(!(cond)) error(msg);}
flush()=do { } while (0)
get_byte()=(inptr < insize ? inbuf[inptr++] : fill_inbuf())
NO_INFLATE_MALLOC=
OF(args)=args
putc(ch)=icedcc_putc(ch)
putstr=printf
putstr_info(x)=
putstr_info=putstr
STATIC=static
Trace(x)=
Trace(x)=fprintf x
Tracec(c,x)=
Tracec(c,x)={if (verbose && (c)) fprintf x ;}
Tracecv(c,x)=
Tracecv(c,x)={if (verbose>1 && (c)) fprintf x ;}
Tracev(x)=
Tracev(x)={if (verbose) fprintf x ;}
Tracevv(x)=
Tracevv(x)={if (verbose>1) fprintf x ;}
WSIZE=0x8000
__ptr_t=void *
Unresolved includes (from headers in index):
Unresolved inclusion: linux/compiler.h in file file:/home/cfarmer/test/newsdk2/linux/lib/inflate.c
Scanner problems:
Unresolved inclusion: <linux/string.h> in file: /home/cfarmer/test/newsdk2/linux/arch/arm/boot/compressed/misc.c:21
Unresolved inclusion: <linux/compiler.h> in file: /home/cfarmer/test/newsdk2/linux/arch/arm/boot/compressed/misc.c:29
Unresolved inclusion: <mach/uncompress.h> in file: /home/cfarmer/test/newsdk2/linux/arch/arm/boot/compressed/misc.c:30
Unresolved names:
Attempt to use symbol failed: size_t in file /home/cfarmer/test/newsdk2/linux/arch/arm/boot/compressed/misc.c:98
Attempt to use symbol failed: size_t in file /home/cfarmer/test/newsdk2/linux/arch/arm/boot/compressed/misc.c:141
[b]For the "show me" people (like myself):[/b]
[cfarmer@fc10.bmcbuild ~]$ ls -l /home/cfarmer/test/newsdk2/linux/include/linux/string.h
-rw-rw-r-- 1 cfarmer cfarmer 3344 2016-02-15 13:49 /home/cfarmer/test/newsdk2/linux/include/linux/string.h
[cfarmer@fc10.bmcbuild ~]$ ls -l /home/cfarmer/test/newsdk2/linux/include/linux/compiler.h
-rw-rw-r-- 1 cfarmer cfarmer 5771 2016-02-15 13:49 /home/cfarmer/test/newsdk2/linux/include/linux/compiler.h
[cfarmer@fc10.bmcbuild ~]$ ls -l /home/cfarmer/test/newsdk2/linux/arch/arm/mach-pilot3bulldc/include/mach/uncompress.h
-rw-rw-r-- 1 cfarmer cfarmer 40 2016-02-15 13:49 /home/cfarmer/test/newsdk2/linux/arch/arm/mach-pilot3bulldc/include/mach/uncompress.h
As far as simple test case is concerned, I understand the benefit, but I've never had a problem with hello world. Creating a useful simple test case would involve a lot of trial-and-error or knowing what the problem is.
|
|
|
| Re: Simple test case not finding include files [message #1781638 is a reply to message #1781632] |
Fri, 09 February 2018 22:52 |
Chad Farmer
Messages: 7
Registered: February 2018 |
Junior Member |
|
|
I've been looking at the log file for Index -> Create Parser Log Files for ./arch/arm/boot/compressed/misc.c.
Despite parsing misc.c, "Unresolved includes (from headers in index):" starts with a reference to inflate.c. This is because misc.c contains 248:#include "../../../../lib/inflate.c"
I looked at the report labeled "Macro definitions (from files actually parsed):". These macros appear to be defined in misc.c. Unfortunately, they are reported in alphabetical order, not scan order. And it does not report the file/line # where defined. But it appears the the parser is not processing #ifdef statements.
File misc.c contains the following lines:
/* Diagnostic functions */
#ifdef DEBUG
# define Assert(cond,msg) {if(!(cond)) error(msg);}
# define Trace(x) fprintf x
# define Tracev(x) {if (verbose) fprintf x ;}
# define Tracevv(x) {if (verbose>1) fprintf x ;}
# define Tracec(c,x) {if (verbose && (c)) fprintf x ;}
# define Tracecv(c,x) {if (verbose>1 && (c)) fprintf x ;}
#else
# define Assert(cond,msg)
# define Trace(x)
# define Tracev(x)
# define Tracevv(x)
# define Tracec(c,x)
# define Tracecv(c,x)
#endif
The CDT editor correctly shades the first section as not being used (DEBUG is not defined). But the parse log output shows values defined from BOTH LEGS of the #ifdef.
I don't know what to say about that. Skipping conditional code seems so fundamental that I must be missing something obvious. Help.
The parser log file includes the following:
Macro definitions (from files actually parsed):
arch_error(x)=
. . .
STATIC=static
Trace(x)=
Trace(x)=fprintf x
Tracec(c,x)=
Tracec(c,x)={if (verbose && (c)) fprintf x ;}
Tracecv(c,x)=
Tracecv(c,x)={if (verbose>1 && (c)) fprintf x ;}
Tracev(x)=
Tracev(x)={if (verbose) fprintf x ;}
Tracevv(x)=
Tracevv(x)={if (verbose>1) fprintf x ;}
WSIZE=0x8000
__ptr_t=void *
|
|
|
| Re: Simple test case not finding include files [message #1781640 is a reply to message #1781638] |
Sat, 10 February 2018 03:51 |
David Vavra
Messages: 1426
Registered: October 2012 |
Senior Member |
|
|
The problem likely resulted from a misinterpreted #if
CDT doesn't handle these well especially if multiple interpretations are possible.
One reason is the cache can have only one value and the value may depend on the reading order.
You could try using the -E GCC option to get the output of the preprocessor.
It's not necessarily what CDT is doing but it may provide a clue.
Reading it would be tedious.
Equally tedious is to comment out large sections of code to shorten the scan.
Doing this judiciously may pinpoint the place where CDT goes wrong.
This is really just making a smaller example that eventually grows.
Sorry about the generalities but without all of your code there isn't much anyone else can do.
Needless to say, nothing jumps out at me.
UPDATE:
You could try forcing the values used by #if that only the CDT parser can see.
Surround them like so:
#ifdef __CDT_PARSER__
:
#define SAMPLE 1
:
#endif
[Updated on: Sat, 10 February 2018 04:25] Report message to a moderator |
|
|
| Re: Simple test case not finding include files [message #1781742 is a reply to message #1781640] |
Mon, 12 February 2018 21:43 |
Chad Farmer
Messages: 7
Registered: February 2018 |
Junior Member |
|
|
Again, thank you for helping. I don't understand what some of the Indexer options actually do, so I might have a setting that is preventing the result I want.
I have specified Indexer options:
Set Project Specific Settings
Set Store Settings with Project, Enable Indexer
Set Index source files not included in the build (Since I'm not building with Eclipse, I assume it doesn't know which files are included. If it is looking for existing ".o" files, I can could set this.)
Set Index unused headers are C files
Not set index all header variants (I don't know what it does, but setting it does not help my problem.)
Set Index source and header files opened in editor (I don't now if this matters.)
Not set Allow heuristic resolution of includes (seems enable less-than-correct parsing in the name of speed.)
Set skip files larger than to 100 MB (I don't want to skip files.)
Not set any of of the "Skip" options.
Set Use a fixed build configuration (Not sure what active does.)
I need for CDT to follow the C preprocessor rules as it is parsing each source file. I'm willing to let the parser run for hours if it will produce results that match the actual build. The Fast/Full option seems to have disappeared. Is Full now the default?
I disabled The GCC Build Output Parser, because I wasn't sure what it did with Linux. Since I've done a Linux build, there is a <module>.o file (ELF with debug) and a .<module>.o.cmd file (gcc command line with -D, -I, -include, etc.) for every module built. My guess was the BOP wanted to run build (make) commands to see the output. Is there a BOP that looks at existing .o and .cmd files to guide the parser?
I'm not sure what you mean by " the cache can have only one value and the value may depend on the reading order". For any line of source (including #if statements) a macro is either undefined or has one value.
|
|
|
| Re: Simple test case not finding include files [message #1781748 is a reply to message #1781742] |
Tue, 13 February 2018 00:05 |
David Vavra
Messages: 1426
Registered: October 2012 |
Senior Member |
|
|
Quote:For any line of source (including #if statements) a macro is either undefined or has one value.
FWIW: undefined is also a value.
Think of it as similar to the floating value NaN.
Eclipse CDT uses caching to accelerate the scan.
Presumably by obviating the rereading of headers.
The cache can retain only one value -- the latest encountered.
This means that a macro with multiple definitions may have the wrong value when evaluated.
You can try disabling the indexer but this means that no values will be remembered.
You can try playing with the Indexer options but I don't think you can turn off caching.
If you have macros with multiple values (say configuration macros) you can try forcing them as I mentioned above.
There is a way to specify that the active configuration would be used. Not sure if that means there are multiple indices.
Another option might be to keep multiple configurations in separate projects.
[Updated on: Tue, 13 February 2018 11:44] Report message to a moderator |
|
| |
| Re: Simple test case not finding include files [message #1783322 is a reply to message #1781320] |
Mon, 12 March 2018 03:46 |
Missing name Mising name
Messages: 35
Registered: September 2010 |
Member |
|
|
Here's my 2 cents! :)
I administer our Eclipse Program configurations which may include several projects. I'm continually refining our configurations based on user feedback.
I have found that Eclipse does a very good job at parsing source (.c/.h) source files for symbol information.
We use Eclipse for editing, static code analysis (codan), syntax highlighting, custom code style formatter, custom code templates and building.
Our build is script driven; we don't build with any Eclipse support tool chains. But to get the indexer support, a supported toolchain needs to be selected. Getting the indexer to behave the way we require, took many hours of trail & error. Including many 'start overs' (starting a workspace & project from scratch).
So I've included screen captures about creating a 'C' project (externally built) and indexer configuration. Hopefully, it helps. The one negative about Eclipse CDT is that sometimes there are interactions which are obscure. ;(
We build C programs for embedded platforms on Windows 7.
Tim
Major System Configuration:
Windows 7 64-bit
Eclipse IDE for C/C++ Developers
v 4.6.2 (Neon)
v 4.7.3a (Oxygen)
v 4.8r (Photon)
v 2018_09
PyDev
MinGW
MSys
GNU Toolchain
Perforce
|
|
|
Goto Forum:
Current Time: Thu Apr 25 13:16:59 GMT 2024
Powered by FUDForum. Page generated in 0.03403 seconds |
] 
Search
Help
Register
Login
Home
