Re: [cedet-semantic] Issue with semantic-lex-c-preprocessor, cedet 1.0pre6

[Eric M. L. <er...@si...>]

Hi,

  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
smoothly.

Eric

>>> kiwilex <ki...@gm...> seems to think that:
>
>Eric,
>
>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 ?
>
>Thanks,
>
>Cyril
>
>2009/3/24 Eric M. Ludlam <er...@si...>
>
>> >>> kiwilex <ki...@gm...> 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:                       er...@si...
   Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net