[GCC-XML] GCCXML and sigc++ 2.0.18

[Brad King]

Julian Bunn wrote:
> I am having trouble with GCCXML (0.9.0) parsing slot.h in version 2.0.18 of
> sigc++. I'm not quite sure how to tackle this, or what the problem is.
> 
> I'm not even sure if I should be asking here :-)
> 
> Any suggestions gratefully accepted.
> 
> $ "J:/gccxml/bin/bin/debug\gccxml.exe"  
> "../libsigc++-2.0.18/sigc++/signal.h" -fxml=signal.xml
> In file included from ../libsigc++-2.0.18/sigc++/signal_base.h:28,
>                  from ../libsigc++-2.0.18/sigc++/signal.h:8:
> ../libsigc++-2.0.18/sigc++/functors/slot.h: In static member function 
> 'static T_return sigc::internal::slot_call1<T_functor, T_retur
> n, T_arg1>::call_it(sigc::internal::slot_rep*, typename 
> sigc::type_trait<T_arg3>::take)':
> ../libsigc++-2.0.18/sigc++/functors/slot.h:136: error: expected `(' 
> before '>' token

It looks like that line has a macro that is defined with various 
compiler work-arounds.  Which definition of the macro gets used is 
determined at preprocessing time.  Since gccxml pretends to be the 
native compiler at preprocessing time the package is selecting the wrong 
options.  The fix is to teach the code (libsigc++) about gccxml as if it 
were another compiler.  It can recognize gccxml using the "__GCCXML__" 
preprocessor symbol.  The Boost C++ project has already done this and is 
gccxml-aware.

I just took a quick look at the libsigc++ source.  It looks like they do 
a configure-time check for this compiler feature and then hard-code the 
configured sigc++config.h header with the answer.  Something in there 
will have to change to recognize gccxml at preprocessing time even when 
the header has been configured with another compiler.  You'll have to 
bring this up with the authors of libsigc++.

-Brad