Hi Eric,

I manage to get the cvs version and I use (add-to-list 'semantic-lex-c-preprocessor-
symbol-file ....) and it's now working :-)

Thanks you very much for your support.


2009/3/26 kiwilex <kiwilex@gmail.com>

I will try the new version on CVS as soon as possible (next week probably)

Thanks a lot.


2009/3/26 Eric M. Ludlam <eric@siege-engine.com>


 In that case, it probably didn't know EXPORTAPI was a lexical
symbol.  If the spp table were dumped, it would probably not be
there.  It would then assume it is a type name because it shows up as:

const EXPORTAPI foo();

so in this case, it looks like some arbitrary data type.

 Were you able to get the CVS version of CEDET?  In it I added the
declspec keyword so if you set semantic-lex-c-preprocessor-symbol-file
to include the header with EXPORTAPI it it, things should then go


>>> kiwilex <kiwilex@gmail.com> seems to think that:
>I have perhaps some clue to help concerning this issue. I have run the
>command (semantic-analyze-debug-assist) and I have the following
>Unable to find datatype for: "const EXPORTAPI".
>Declared type is: nil
>why the parse do not consider only EXPORTAPI ?
>Have you any idea ?
>2009/3/24 Eric M. Ludlam <eric@siege-engine.com>
>> >>> kiwilex <kiwilex@gmail.com> seems to think that:
>> >Hi,
>> >
>> >Thanks for your reply
>> >
>> >For this example, I have only set the macro in the
>> >semantic-lex-c-preprocessor-symbol-map. I do not have huse
>> >semantic-lex-c-preprocessor-symbol-file.
>> >
>> >This is strange. Perhaps my emacs version has some trouble. I don't know.
>> >Moreover, if I replace EXPORTAPI with __THROW which is defined in
>> >semantic-lex-c-preprocessor-symbol-file-built-in the parse is ok.
>> Well, it seems things are ok for your config.  I just can't guess what
>> the problem is.
>> >I have looked quickly a the code, and I wonder if the value generated for
>> >semantic-lex-spp-macro-symbol-obarray is ok ?
>> >
>> > [0 0 EXPORTAPI 0 __THROW 0 0 0 __restrict 0 0 0 0]
>> >
>> >Concerning active macro this would be great but user should define wich
>> >macro is used to do such thing like NDEBUG ....
>>   [ ... ]
>> An obarray is a vector of symbols.  If you have an obarra "Ob", you
>> would access it like this:
>>  (let ((sym (intern-soft "EXPORTAPI" Ob)))
>>    (symbol-value sym))
>> where 'sym' is a symbol that is not in the global symbol space.  When
>> you print an obarray, it shows up as a vector of symbols.  The symbols
>> don't print their values, but they are there.  That is why the special
>> dump command is needed to map all the symbol atoms to some print
>> routine.  See `semantic-lex-spp-macros' for details on mapping across
>> obarrays.
>> Eric
 [ ... ]

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