This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Provide way to get right include/macro for *headers*. All NativeFileItem in: NativeProject.getAllHeaderFiles() should have nonempty: NativeFileItem.getSystemIncludePaths() NativeFileItem.getUserIncludePaths() NativeFileItem.getSystemMacroDefinitions() NativeFileItem.getUserMacroDefinitions() Now only "source" files have non empty NativeFileItem providers, we need all project files to have this information (may be define some "default" settings). To see the problem: Create Application project. Add include file "newfile.h" with content: #ifndef _newfile_H #define _newfile_H #include <stdio.h> #endif as result there will be > SEVERE: failed resolving path from /home/as204739/Application3/newfile.h for TOKEN{["#include ",<11>,line=11,col=1],offset=133,file=null} INCLUDE{<S> ["<stdio.h>",<201>,line=11,col=10],offset=142,file=null} and the reason described above.
This is not easy to 'fix'. To correctly parse an orphan header file (header file not used as include in any source file) you will need system and project level include files and macros, but which ones? From the C compiler or from the C++ compiler? There is no right choice and any choice could be be wrong. A header file don't (by default) have a compiler associated with it so there is no way to tell what is the right settings to use. And if you associate a compiler with the header file, then it would mean it should be compiled as a file (which would be wrong in managed projects). What does other IDE do in this situation? Here is a work-around: I could implement 4 project level methods getSystemIncludePaths(Compiler), getUserIncludePaths(Compiler), ... similar to the ones you use from NativeFileItem. You will then need to find the project from the NativeFileItem (the header file), get the lists from the project using your favorite compiler (C or C++) and apply them to the parser when you parse the headerf ile. This would work but make your code dependent on MakeProject which I'm not sure you want. An alternative solution is to add these new methods to NativeProject and somehow let you specify the language. This would be easier for you to do but require we change the public interface NativeProject which other groups also use. I could also hack the code so it always would return the C++ settings from the project for any file that doesn't have a compiler associated with it, but this is really ugly. What do you think?
We aggreed to add 4 new methods to NativeProject: /** * Returns a list <String> of compiler defined include paths used when parsing 'orpan' source files. * @return a list <String> of compiler defined include paths. * A path is always an absolute path. * Include paths are not prefixed with the compiler include path option (usually -I). */ public List/*<String>*/ getSystemIncludePaths(); /** * Returns a list <String> of user defined include paths used when parsing 'orpan' source files. * @return a list <String> of user defined include paths. * A path is always an absolute path. * Include paths are not prefixed with the compiler include path option (usually -I). */ public List/*<String>*/ getUserIncludePaths(); /** * Returns a list <String> of compiler defined macro definitions used when parsing 'orpan' source files. * @return a list <String> of compiler defined macro definitions. * Macro definitions are not prefixed with the compiler option (usually -D). */ public List/*<String>*/ getSystemMacroDefinitions(); /** * Returns a list <String> of user defined macro definitions used when parsing 'orpan' source files. * @return a list <String> of user defined macro definitions. * Macro definitions are not prefixed with the compiler option (usually -D). */ public List/*<String>*/ getUserMacroDefinitions();
implemented and fixed.