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.
Hi, I have an automake project that installs header files from the project directory to /usr/local/include by default. In NetBeans I configured the code parser to parse ONLY the project's include dir but not /usr/local/include -- however I still found that NetBeans automatically parses /usr/include and /usr/local/include and links the project .h files found there to my .cpp code, which is not what I want (by default, /usr/local is read-only). Hence when I clicked the "source/header" toggle button I always have the outdated .h in /usr/local/include with read-only attribute. Furthermore, the parser sometimes hangs up on parsing for no obvious causes and I would suspect that may be something to do with the duplicated appearances of .h files in two different locations. As a second issue, the parser's performance for extremely template-intensive project is not great and sometimes hang-ups occur (a typical example is the CGAL library; although for mid-size projects like boost it is impressive). I hereby report the above issues in the hope of possible solutions. Regards, Xiaofan
Hi, Xiaofan, Thanks for your report. I have some questions: What do you mean by >I configured the code parser to parse ONLY the project's include dir but not /usr/local/include? Have you removed in settings Tools->Options->C++->Code Assistance the folder /usr/local/include for your compiler? As about slow parsing of intensive template-based projects. We are working on improving performance. Btw, do you mean performance problems in applications which use CGAL or developing CGAL itself?
Hi vv159170, I did not realise there is a global includedir setting in Options->C++ in addition to the project one. Your suggestion solved my problem after I created a new nbproject for the makefile proj with this new setting (the original nbproject still parsed the wrong thing probably due to cache reasons). Thanks and in light of this minor problem, I think it would be better if NB can arrange the priority of parsing includedirs so that project-specific dirs are parsed firstly and system-wide secondly. And any duplicates will be automatically ignored in secondary dirs. I'm not sure whether that seems a more practical order. In regards to the CGAL issue, I am a user of the library so I did not touch its source code (so it was pure .h parsing for my project). I used the Skin_surface package and sometimes, but not always, when NB parses the library because of an #include to its headers, the NB parser hangs (with 1 of the CPU cores locks with 100% usage) and makes the IDE nearly non-responsive. The CPU usage plot gave me the idea that the parse repetitively tried to do something but kept on failing doing so (but would not abandon attempting). Regards, Xiaofan
Hi, Xiaofan Btw, do you use 6.5 version or 6.1? I've tried in 6.5: -created project -created Main C++ file which by default has #include <stdlib.h> directive -created header file stdlib.h -in project properties set "." as additional include directives => after that hyperlink on #include <stdlib.h> goes to project's file, not system include Thanks, Vladimir.
Hi, Just to leave a note here that I'd also recommend a test with QT4.3/4.4, along with CGAL and other libraries when you have the improved code parser in future versions. I recently observed that QT headers could sometimes hang up the parser, too, with its huge number of header/preprocessing directives. This is just a suggestion. Regards, Xiaofan
Original issue duplicates IZ#116334 and was fixed. Performance of code model was improved since issue had filed. See IZ#159563. So I close issue as fixed. If performance is still bad, please file separate issue.