Thanks Brad: this is very useful. I will check to see that I have the
correct sigc++ configuration in
my set up before worrying the authors: it's possible I have
inadvertently used the wrong flags.
Julian
Brad King wrote:
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
