Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.13) Gecko/2009080315 Ubuntu/9.04 (jaunty) Firefox/3.0.13 Build Identifier: I20090611-1540 Hi, I'm using Eclipse Galileo and the most recent (stable) CDT environment for Linux kernel development. I've set up the project as a 'Makefile Project' and I'm cross-compiling from i686 to ARM. My feature suggestion is to make the 'built-in' headers adjustable (i.e. delete/repriorities) for a CDT Makefile project. In many makefile projects, built-in header files should definitely take priority over the ones that the CDT claims are built-in (especially when the project specificies -nostdinc in the Makefile). Currently, Eclipse will often (almost always) bring up the wrong header file when I Ctrl+click on a struct, include, function, or macro. The reason for this is that I'm using the default 'Linux GCC' configuration, and it will not allow user deletion / prioritizing of the 'built-in' include/header paths, as defined in Project->Properties->C/C++ General->Paths and Symbols->Includes->GNU C . My project-specific include paths are listed in priority from bottom to top. They are all 'workspace paths'. /linux-2-6/include /linux-2.6/arch/arm/include /linux-2.6/arch/arm/mach-pxa/include However, there are 4 'built-in' paths that are of absolutely no use to me, and I cannot delete them or set my include paths to a higher priority (i.e. put them lower in the list-view). /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.3.3/include /usr/lib/gcc/i486-linux-gnu/4.3.3/include-fixed /usr/include Subsequently, if I Ctrl+click on something that says '#include <linux/i2c.h>' in any file I'm editing, then Eclipse opens /usr/include/linux/i2c.h, rather than /linux-2.6/include/i2c.h (workspace path). They are actually completely different files, which does often happen with kernel development. My build command is make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- I've changed the 'Make build target' to 'zImage modules' as opposed to 'all' for 'Build(incremental build)'. The build works, but the content assist and IDE only offer a marginal amount of usefulness. Likely due to this as well, Eclipse will not properly parse printk(...) siting a syntax error, in spite of defining the __KERNEL__ symbol in the project properties. Perhaps there's somebody with some Linux kernel development experience who can tell me exactly what I'm doing wrong. Reproducible: Always Steps to Reproduce: 1. Create a Makefile project 2. Check out linux kernel sources 3. Add workspace paths 4. Add __KERNEL__, CONFIG_PRINTK symbols to project properties 5. Open a file that includes <linux/i2c.h> 6. Ctrl+click on linux/i2c.h 7. Observer that /usr/include/linux/i2c.h is opened. Really, for Makefile projects, since they're only used for parsing the C source code, 'built-in' include paths should be completely user-manageable.
(In reply to comment #0) > In many makefile projects, > built-in header files should definitely take priority over the ones that the > CDT claims are built-in (especially when the project specificies -nostdinc in > the Makefile). Sorry, that should read: > built-in header files should definitely take priority over workspace paths > (especially when the project specificies -nostdinc in > the Makefile).
arg! (In reply to comment #1) > Sorry, that should read: > > > built-in header files should definitely NOT take priority over workspace paths > > (especially when the project specificies -nostdinc in > > the Makefile).
Woops... I guess this is my bad (you may have guessed with how bad my typing is). I think I may have just forgotten the leading 'l' in /linux-2.6/include, which was probably the most important of the workspace include paths. It seems to be working fine now. Sorry for any inconvenience.
Regardless, I think a request to allow more control over built-in entries is legitimate.
I agree we need a button to remove/disable "build-ins". "Build-in" In quotes because it is comes from scanner discovery which is not that good. I was fighting to remove some of the entries from the list. End-up editing xml file. They were still coming back sometimes. Yikes. So I will re-open this bug for this purpose (unless we find a duplicate)
There are a few bugs around like bug 197955, bug 206372, bug 273144 but they do not say remove built-ins explicitly. Arguably they all together could make this one duplicate. The thing is that we need to have control over these entries in UI.
