CEDET

>>> Nathan Huesken <cedet@...> seems to think that:
>Hi,
>
>I have the following in my .emacs:
>(setq-mode-local c-mode
>			 semanticdb-find-default-throttle
>				 '(project unloaded system recursive))
>(setq-mode-local c++-mode
>			 semanticdb-find-default-throttle
>				 '(project unloaded system recursive))
>
>Now, if my source file include the following:
>#include <ClanLib/core.h>
>
>CL_Ve is not completed (it is supposed to complete to CL_Vector2).
>CL_Vector2 is not directly defined in ClanLib/core.h. It is defined in ClanLib/Core/Math/vector2.h, which is included by ClabLib/core.h
>
>If I do:
>#include <ClanLib/Core/Math/vector2.h>
>
>CL_Ve is completed correctly.
>So I assume that cedet does not check recursivly in system header files.
>
>Can I make it do it?
  [ ... ]

Hi,

  Headers are searched recursively, but perhaps clanlib includes their
headers using a different include path.

  A quick way to find it is to do this:

M-x semanticdb-find-adebug-lost-includes RET

  or, (and check this out) see the context menu attached to include
file statements in your C file, which gives you more options for
figuring out where your lost include may have gotten to.

  In that output, you might see:

  Math/vector2.h

  which means the compiler has /wherever/ClanLib/Core on the path,
where you might just have /wherever/ClanLib on the Emacs path.

Does this make sense?

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Hi,

I found out the following:
So far I had this:
(semantic-reset-system-include 'c++-mode)
(semantic-add-system-include "/usr/include" 'c++-mode)
(semantic-add-system-include "/usr/include/ClanLib-0.8" 'c++-mode)

If I add
(semantic-add-system-include "/usr/include/ClanLib-0.8/ClanLib" 'c++-mode)

Now, CL_Vector2 is found!
CL_Vector2 is included over the file

/usr/include/ClanLib-0.8/ClanLib/core.h

With the statement:
#include "Core/Math/math.h"

Now, the path Core/Math/math.h is incorrect relative from my system include-path, but corrct from the path in which core.h is.
Maybe semantic does not take this into account?

Thanks!
Nathan

On Sun, May 04, 2008 at 08:02:05AM -0400, Eric M. Ludlam wrote:
> >>> Nathan Huesken <cedet@...> seems to think that:
> >Hi,
> >
> >I have the following in my .emacs:
> >(setq-mode-local c-mode
> >			 semanticdb-find-default-throttle
> >				 '(project unloaded system recursive))
> >(setq-mode-local c++-mode
> >			 semanticdb-find-default-throttle
> >				 '(project unloaded system recursive))
> >
> >Now, if my source file include the following:
> >#include <ClanLib/core.h>
> >
> >CL_Ve is not completed (it is supposed to complete to CL_Vector2).
> >CL_Vector2 is not directly defined in ClanLib/core.h. It is defined in ClanLib/Core/Math/vector2.h, which is included by ClabLib/core.h
> >
> >If I do:
> >#include <ClanLib/Core/Math/vector2.h>
> >
> >CL_Ve is completed correctly.
> >So I assume that cedet does not check recursivly in system header files.
> >
> >Can I make it do it?
>   [ ... ]
> 
> Hi,
> 
>   Headers are searched recursively, but perhaps clanlib includes their
> headers using a different include path.
> 
>   A quick way to find it is to do this:
> 
> M-x semanticdb-find-adebug-lost-includes RET
> 
>   or, (and check this out) see the context menu attached to include
> file statements in your C file, which gives you more options for
> figuring out where your lost include may have gotten to.
> 
>   In that output, you might see:
> 
>   Math/vector2.h
> 
>   which means the compiler has /wherever/ClanLib/Core on the path,
> where you might just have /wherever/ClanLib on the Emacs path.
> 
> Does this make sense?
> 
> Eric
> 
> -- 
>           Eric Ludlam:                       eric@...
>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

I think you are right.  Semantic always puts the current directory on
the path, but I think that data may be lost for the recursive
includes.  I'll add that to my todo list to fix.

Eric

>>> Nathan Huesken <cedet@...> seems to think that:
>Hi,
>
>I found out the following:
>So far I had this:
>(semantic-reset-system-include 'c++-mode)
>(semantic-add-system-include "/usr/include" 'c++-mode)
>(semantic-add-system-include "/usr/include/ClanLib-0.8" 'c++-mode)
>
>If I add
>(semantic-add-system-include "/usr/include/ClanLib-0.8/ClanLib" 'c++-mode)
>
>Now, CL_Vector2 is found!
>CL_Vector2 is included over the file
>
>/usr/include/ClanLib-0.8/ClanLib/core.h
>
>With the statement:
>#include "Core/Math/math.h"
>
>Now, the path Core/Math/math.h is incorrect relative from my system
>include-path, but corrct from the path in which core.h is.  Maybe
>semantic does not take this into account?
>
>Thanks!
>Nathan
>
>On Sun, May 04, 2008 at 08:02:05AM -0400, Eric M. Ludlam wrote:
>> >>> Nathan Huesken <cedet@...> seems to think that:
>> >Hi,
>> >
>> >I have the following in my .emacs:
>> >(setq-mode-local c-mode
>> >			 semanticdb-find-default-throttle
>> >				 '(project unloaded system recursive))
>> >(setq-mode-local c++-mode
>> >			 semanticdb-find-default-throttle
>> >				 '(project unloaded system recursive))
>> >
>> >Now, if my source file include the following:
>> >#include <ClanLib/core.h>
>> >
>> >CL_Ve is not completed (it is supposed to complete to CL_Vector2).
>> >CL_Vector2 is not directly defined in ClanLib/core.h. It is defined in ClanLib/Core/Math/vector2.h, which is included by ClabLib/core.h
>> >
>> >If I do:
>> >#include <ClanLib/Core/Math/vector2.h>
>> >
>> >CL_Ve is completed correctly.
>> >So I assume that cedet does not check recursivly in system header files.
>> >
>> >Can I make it do it?
>>   [ ... ]
>> 
>> Hi,
>> 
>>   Headers are searched recursively, but perhaps clanlib includes their
>> headers using a different include path.
>> 
>>   A quick way to find it is to do this:
>> 
>> M-x semanticdb-find-adebug-lost-includes RET
>> 
>>   or, (and check this out) see the context menu attached to include
>> file statements in your C file, which gives you more options for
>> figuring out where your lost include may have gotten to.
>> 
>>   In that output, you might see:
>> 
>>   Math/vector2.h
>> 
>>   which means the compiler has /wherever/ClanLib/Core on the path,
>> where you might just have /wherever/ClanLib on the Emacs path.
>> 
>> Does this make sense?
>> 
>> Eric
>> 
>> -- 
>>           Eric Ludlam:                       eric@...
>>    Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
>Don't miss this year's exciting event. There's still time to save $100. 
>Use priority code J8TL2D2. 
>http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>_______________________________________________
>cedet-semantic mailing list
>cedet-semantic@...
>https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net