I manage to get the cvs version and I use (add-to-list 'semantic-lex-c-preprocessor-
I will try the new version on CVS as soon as possible (next week probably)
Thanks a lot.
Cyril2009/3/26 Eric M. Ludlam <firstname.lastname@example.org>
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 <email@example.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 <firstname.lastname@example.org>
>> >>> kiwilex <email@example.com> seems to think that:
>> >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
>> >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
[ ... ]
Eric Ludlam: firstname.lastname@example.org
Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net