[sigc] Re: perl wrappers for libsigc++2 [was: Re: libsigc++ article]

Am 2003.11.08 21:23 schrieb(en) rsteinke w-link net:

> From: Martin Schulze <martin-ml hippogriff de>
> Am 2003.11.03 16:27 schrieb(en) Murray Cumming:
> > [snip]
> >
> > libsigc++ could distribute the generated .h and .cc files instead,
> > that would help, and I would accept a patch to do that. For
> > gtkmm distributes generated files.
> Whether or not we distrubute the generated files, we need to also
> distribute the .m4 files since people use the macros defined there
> to generate templates / template specializations for > 7 arguments.
> Also the perl bindings seem to use our .m4 files.

What the perl wrapper is using is template.macros.m4, to generate
for Signal0, Signal1, etc. Since the behavior of the macros in this
file has
changed between 1.2 and 2.0, exporting it doesn't have the benefit of
the perl wrapper support 1.2 and 2.0 simultaneously. I can see two
fixes for
this situation:

1.) Have the perl wrapper grab a copy of template.macros.m4 out of the
1.2 tree
and use that. Since the helper library that uses these macros is LGPL,
issues shouldn't be a concern, and this would allow simultaneous
support of 1.2
and 2.0 with some #ifdefs.

2.) For 2.0 support, change the perl wrapper to wrap sigc::signal
instead of
SigC::Signal[0-7]. The perl wrapper would then not need to generate
wrappers for different kinds of signals, and wouldn't need the macros
at all.

I think I'll probably do 1) at first, and move to 2) at some point to
allow me
a chance to examine some of the design decisions in the perl wrapper
(in particular,
the wrapper for slot will probably move more to the perl side from the
C++ side).
Do we have any idea yet what the C++ API is likely to to in later
versions (2.2?
3.0?) so I can plan around that? In any case, exporting the m4 macros
files in
2.0 won't actually help the perl wrapper.

Later versions could make use of new C++ features that would help to
remove the last hindfoots from the API like the need to specify
a typedef result_type or lacking support for multi-type functors.
This would be 2.2. There are no plans for 3.0 - by that time there
might well be a signal&slot implementation in stl.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]