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.
I have a very slowly and carefully created set of includes created by editing the include directories in Tools->Options->C++->Code Assistance. My localhost one contains 30 directories letting my edit a program which uses many obscure Gnome library APIs (the program creates a gnome-panel applet). The list of include directories contains directories for multiple Linux releases so that I can run netbeans on many different Linux platforms and versions using the same set of includes. Most of the directories follow the pattern: /usr/include/c++/x.y[/*] where x.y is the gcc version of that platform. For instance, 4.1.1 builds on Red Hat 5.5, 4.2 builds on Ubuntu 8.04 (our official build platform) and so on. When I start a new netbeans session, I always get a warning that my tool collection has changed and a link to "Fix Code Assistance". If I press that link, it blows away my 30 directories and replaces them with the default. This default set of includes replaces the correct set of include directories! I'll post an example in a minute...
Gordon, I do not understand why you need to set up system include dirs for different tool collections? Let you have a project with GNU tool collection. Open the project on system with GNU 4.4. Code assistance will use system include paths from /usr/include/c++/4.4[/*]. Open the project on system with GNU 4.3. Code assistance will use system include paths from /usr/include/c++/4.3[/*]. So you should not setup system include paths.
> I do not understand why you need to set up system include dirs for > different tool collections? I use the same userdir on different platforms (RedHat 5.5, Red Hat 6, Ubuntu 8.04 - 11.04, SuSE, ... . I got tired of having syntax errors whenever I switched platforms, so I put together this toolchain which works on all of my supported platforms. However, the problem shows up on a single platform. After I opened this issue I spent an hour putting together an example. I thought I saved it, but its not here now! I'll recreate it, but it shows the problem in a repeatable manner on a single Linux platform.
My example is from http://projects.gnome.org/ORBit2/appletstutorial.html. Copy/paste the C code into applet.c and the compile line into a Makefile (you may have to replace the $(pkg-config ...) part with `pkg-config ...` depending on your Linux distro). I compiled the example on Ubuntu 11.04 and have done the same example on older Ubuntu distros back to 8.04 (our primary build platform). You'll need to add about a dozen GNOME packages to be able to compile. Here is the list: libpango1.0-dev libgdk-pixbuf2.0-dev libatk1.0-dev liborbit2-dev linux-libc-dev libbonobo2-dev libgtk2.0-dev libglib2.0-dev libbonoboui2-dev libbonobo2-dev libcairo2-dev libpanel-applet2-dev Once you've installed those packages (# apt-get install <package-name>) you should be able to compile applet.c. Once you've compiled it, make a Makefile project and open applet.c in the editor. You'll see both both include files have yellow triangles and if you start drilling down, you'll find missing include files. Add the include directories for the above packages: /usr/include/pango-1.0 /usr/include/gdk-pixbuf-2.0 /usr/include/atk-1.0 /usr/include/orbit-2.0 /usr/include/i386-linux-gnu /usr/include/bonobo-activation-2.0 /usr/include/gtk-2.0 /usr/include/glib-2.0 /usr/include/libbonoboui-2.0 /usr/include/libbonobo-2.0 /usr/include/cairo /usr/lib/i386-linux-gnu/glib-2.0/include /usr/lib/gtk-2.0/include /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include-fixed Reparse you're project (another minor issues is that I had to reparse at least 10-15 times while adding these directories one at a time). Now applet.c and all include files should show green (ie, no syntax errors or warnings). Exit netbeans (and possibly save toolchain.properties). Now restart netbeans. You'll get the "tools Collection were Changed\nFix Code Assistance" icon in the lower right corner. Go ahead and press the fix link. The include directories you just added are replaced and applet.c is now amber. If you drill into panel-applet.h you'll see all of the includes have their yellow triangles back. Drilling down finds the same unresolved includes. This basically makes the syntax highlighting unusable! With me the problem is even worse. I have that large (30) list of includes in my localhost toolchain, but also have toolchains for various specific machines. If I forget and press the fix button it can make all of my toolchains show syntax errors. I admit that if I press the X icon on each fix link it closes, but I shouldn't have to do this (repeatedly) each time I restart netbeans. Also, someone else could have the same problem and have their includes blown away without understanding how or why. When a button says to Fix Code Assistance, the first reaction is to assume it will fix it and press the button.
(In reply to comment #3) > Once you've installed those packages (# apt-get install <package-name>) you > should be able to compile applet.c. Once you've compiled it, make a Makefile > project and open applet.c in the editor. > > You'll see both both include files have yellow triangles and if you start > drilling down, you'll find missing include files. Add the include directories > for the above packages: > > /usr/include/pango-1.0 > /usr/include/gdk-pixbuf-2.0 > /usr/include/atk-1.0 > /usr/include/orbit-2.0 > /usr/include/i386-linux-gnu > /usr/include/bonobo-activation-2.0 > /usr/include/gtk-2.0 > /usr/include/glib-2.0 > /usr/include/libbonoboui-2.0 > /usr/include/libbonobo-2.0 > /usr/include/cairo > /usr/lib/i386-linux-gnu/glib-2.0/include > /usr/lib/gtk-2.0/include > /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include > /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include-fixed Gordon, this is a user include paths and user defined macros. You should specify it in Project->Properties->Code Assistance. Tool collection code assistance contains only system include paths and macros.
I fail to see how my directories are "user include paths" while /usr/local/include is a system include path! Once upon a time I did put my include dirs in project properties. However, that caused even more issues with invalid syntax errors showing in the editor whenever I switched from one Linux distro to another. Putting the include directories in a toolchain has (up until 7.0) been *much* more reliable.
Given that the fix for 170753 was intended to handle version updates, perhaps that fix could be smarter and only change versioned directories where an updated version exists. That would keep 170753 fixed in a manner which didn't have the negative impact the current solution does.
I agree with gordon. We have "auto" discovered paths and macros in options and by default only them are present in lists. We should mark user specified entries as "non-removable" and leave them after check Not clear what to do with auto detected, but removed by user...
fixed, change set: http://hg.netbeans.org/releases/rev/d8c63b0c7bfb
Integrated into 'main-golden', will be available in build *201105200400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/2bc5b93d1e04 User: Alexander Simon <alexvsimon@netbeans.org> Log: fixed Bug #198489 The "Fix Code Assistance" blows away my system includes! (transplanted from d8c63b0c7bfbea4d7f5ef0ec61a7a98b7a943563)
No QA action needed.