2009/3/24 Eric M. Ludlam
>Hi,Well, it seems things are ok for your config. I just can't guess what
>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.
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)))
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