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.
The attached simple project demonstrates how the internal parser cannot resolve secondary include files when building a project from pre-existing code. The project consists of four files: - src/a.cc (includes a.h and b.h) - include/a.h (includes c.h) - include/b.h (includes c.h) - include/c.h (empty) During construction of the project, specify that ./include as an include directory. Now examine the files. src/a.cc can resolve a.h and b.h, but a.h and b.h cannot resolve c.h. Although there is tooltip feedback now that it can't resolve the path, it is not helpful, because the tooltip should state which include directories it looked in.
Created attachment 68367 [details] This project demonstrates the problem
I opened your project and it works fine without any modifications. Could you, please, remove /tmp/${user}-cnd65... or /var/tmp/${user}-cnd65... folder and try to open project again? Thanks, Vladimir.
You are correct: removing /tmp/toddb-cnd6{0,5}* fixed the issue with the given project. I should note this is highly unexpected... its never good to surprise the user. However, the problem remains, I think, but I'm running out of ideas how to distill the problem from complex projects with thousands of files. I see numerous problems, but don't see tools to resolve them. For example, if I click on Project --> Code Assistance --> show failed include directives, I see the following: - click on a file X.h under "include directives" and in the "Source files" pane it shows a list of files that includes X.h, such as Y.h and Z.h. In most cases it will show the full pathname for these files in the "Sources Related Files" pane. Now if I go to the folder that contains Y.h and Z.h, and check the properties, I can see that the inherited include directories list the folders that contain X.h, Y.h and Z.h. - Another problem is that files that appear in the tree, but are not listed among the files in the project appear both as source files (in the failed include directives dialog) and in the targets of include directives. This might suggest that I must add every file in every source tree, and then exclude it? How can I clarify this for you?
Created attachment 68383 [details] The requested log file.
Please ignore last attachment, as it was intended for another issue.
Created attachment 68462 [details] startup log with fresh user directory
Can't seem to repeat the hang now, with or without fresh user dir.
Again... ignore last attachment. There appears to be a mode where the bug database moves from one bug to the next. Sorry.
This problem (can't resolve include files) is apparently caused by differing views in the IDE. - I have a project created from existing sources where the tree contains several buildable components. - When the project was created, the source directories were specified for the component I wanted to build, however.... - the folders did not show up in the project view, so I added the files to the project; e.g. "add existing item" and "add existing items from folders". - at one point I removed the list of source directories, except for the component I was building, because the project view showed all the files I wanted to see. And because the source folders property did not seem to do anything useful. This last step appears to have caused *some* secondary includes to be unresolvable, even when the include specification points to the location of the include file. I have added source directories to the project properties for all of the subcomponents and now I cannot find any unresolvable include files. It would seem that the project view is not (entirely) considered when trying to resolve includes. Or that the list of source folders has some undefined influence on the traversal of include paths. This is a bit of a problem, because in the project view, I can specifically include or exclude files, but the source folders property does not allow that kind of control. This might suggest that the source folder property should go away and the set of source files should be derived from the project view? Should this be a different bug?
I want to clarify how code assistance resolves include directives. 1. For each source file (C/C++) folders are used: - project user include paths - folder user include paths - file include paths - file path - compiler system include paths Order of resolving is same as in a compiler. 2. For headers no at all include paths. Instead paths from source file used (file that directly or indirectly includes the header). So you cannot directly specify include paths for headers. You can open header file in the editor and see include hierarchy and detect one or some source files that include the header.
Dialog "show failed include directives" was extended: - added information about source file user and system include paths - for headers (that were included) added include paths from source to header For example: lets unresolved "CLucene/config/PlatformUnix.h" in file /export/home/as204739/Projects/sfbay/clucene-0.9.10/src/CLucene/config/compiler.h Content of "Source related files" pane is: ------------------ /export/home/as204739/Projects/sfbay/clucene-0.9.10/src/CLucene/config/PlatformUnix.h Path to header from source file: /export/home/as204739/Projects/sfbay/clucene-0.9.10/src/demo/Statistics.cpp: (line 1) /export/home/as204739/Projects/sfbay/clucene-0.9.10/src/demo/stdafx.h: (line 12) /export/home/as204739/Projects/sfbay/clucene-0.9.10/src/CLucene/StdHeader.h: (line 11) User include paths for source file: /export/home/as204739/Projects/sfbay/clucene-0.9.10/src/CLucene /export/home/as204739/Projects/sfbay/clucene-0.9.10/src/demo System include paths for source file: /usr/sfw/include/c++/3.4.3 /usr/sfw/include/c++/3.4.3/i386-pc-solaris2.10 /usr/sfw/include/c++/3.4.3/backward /usr/local/include /usr/sfw/include /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/include /usr/include ------------------ So we can see that file: /export/home/as204739/Projects/sfbay/clucene-0.9.10/src/demo/Statistics.cpp should have additional user include path: /export/home/as204739/Projects/sfbay/clucene-0.9.10/src Change set: http://hg.netbeans.org/main/rev/78fc41099689
Integrated into 'main-golden', available in build *200808300201* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/78fc41099689 User: Alexander Simon <alexvsimon@netbeans.org> Log: fixing: IZ#145205:Can't resolve secondary includes - extend info in the pane "Source's related files" in the "Filed #include Directives" dialog