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
_______________________________________________
gccxml mailing list
[email protected]
http://www.gccxml.org/mailman/listinfo/gccxml
