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.

Bug 75869 - NativeFileItem.getIncludePaths() should return predefined include paths for the current compiler
Summary: NativeFileItem.getIncludePaths() should return predefined include paths for t...
Status: CLOSED FIXED
Alias: None
Product: cnd
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All All
: P1 blocker (vote)
Assignee: Thomas Preisler
URL:
Keywords:
Depends on:
Blocks: 76265 84408
  Show dependency tree
 
Reported: 2006-05-03 17:14 UTC by Vladimir Kvashin
Modified: 2007-09-06 17:54 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Kvashin 2006-05-03 17:14:56 UTC 
Compilers have a predefined list of include paths. It isn't always /usr/include. 

For example GNU on solaris searches such directories as
/usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/include 
/usr/sfw/include/c++/3.4.3

On SUSE Linux GNU uses /usr/include - but also some its subdirectories (for
example /usr/include/linux, /usr/include/gnu, /usr/include/g++,
/usr/include/g++/backward).

These paths should be added to the list that NativeFileItem.getIncludePaths()
returns.
Comment 1 Vladimir Voskresensky 2006-05-21 12:32:06 UTC 
i.e. GCC includes could be found by analyzing output of C and C++ mode of gcc
after lines
#include "..." search starts here:
#include <...> search starts here:

For C language:
# gcc -x c -v -E - < /dev/null
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.4/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info--mandir=/usr/share/man
--enable-languages=c,c++,f77,objc,java,ada --disable-checking --libdir=/usr/lib
--enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.4 (pre 3.3.5 20040809)
 /usr/lib/gcc-lib/i586-suse-linux/3.3.4/cc1 -E -quiet -v -D__GNUC__=3
-D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=4 -
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc-lib/i586-suse-linux/3.3.4/include
 /usr/i586-suse-linux/include
 /usr/include
End of search list.
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "<stdin>"

For C++ language
# gcc -x c++ -v -E - < /dev/null
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.4/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info--mandir=/usr/share/man
--enable-languages=c,c++,f77,objc,java,ada --disable-checking --libdir=/usr/lib
--enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.4 (pre 3.3.5 20040809)
 /usr/lib/gcc-lib/i586-suse-linux/3.3.4/cc1plus -E -D__GNUG__=3 -quiet -v
-D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=4 -D_GNU_SOURCE -
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/g++
 /usr/include/g++/i586-suse-linux
 /usr/include/g++/backward
 /usr/local/include
 /usr/lib/gcc-lib/i586-suse-linux/3.3.4/include
 /usr/i586-suse-linux/include
 /usr/include
End of search list.
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "<stdin>"
Comment 2 Vladimir Voskresensky 2006-09-08 14:19:56 UTC 
This issue blocks IZ#76265 (http://www.netbeans.org/issues/show_bug.cgi?id=76265)
Comment 3 Vladimir Voskresensky 2006-09-11 13:25:26 UTC 
Rising this issue to P1.
1) We are too long blocked by this issue in our accuracy results for end users.
Even if we can make some hacks for white box testing and get results upto 90%,
user could have bad impressions about quality of code model features (accuracy
less than 50%).
2) It is especially significant problem for Makefile based project, where
include directives and macros can't be configured through project system at all.
Comment 4 julieg 2006-09-21 01:31:55 UTC 
Do we take care of the include paths for Sun's compilers?
Comment 5 Thomas Preisler 2006-10-03 05:55:18 UTC 
Mostly fixed. Left is making the user modifications persistent.
Comment 6 Thomas Preisler 2006-10-06 06:37:40 UTC 
Fixed. Compiler output is not scanned to generate include and macros lists. The
list are also customizable from Options->C/C++ Projects.
Comment 7 Maria Tishkova 2007-08-06 18:02:30 UTC 
I will close this issue as it had to be marked as verified a long time ago, but I will open the new one,
which is kind of related to this one