Re: [sigc] Re: libsigc++ article

[rsteinke w-link net]

Okay, a few more thoughts on my part about the m4 macros files, now that
I've examined the code a bit more.

> From: Murray Cumming <murrayc usa net>
>
> On Sun, 2003-11-02 at 00:07, rsteinke w-link net wrote:
> > Is there a reason the m4 macro files are no longer installed? They were
> > used in the past to allow users to generate signals with large numbers of
> > arguments (10, 12, whatever).
>
> How many arguments do you actually need. If it is just one or two more
> then maybe we can ship libsigc++ with that many.
>
> I can't believe that anybody needs 10 parameter arguments. Even in perl,
> eventually it's time to make an object.

Looking through fucntors/slot.h, I see that the redesign really does limit
you to 7 arguments, due to the way sigc::slot<> is written. This shouldn't
be a problem, I was just remembering the old way where you could generate
more signals easily with macros. That no longer appears to be the case.

What about the retyping functions? Under 1.2, the lib provided one and two
argument hide() functions, and you could generate functions to hide larger
numbers of arguments with the macros. Would providing the macros still allow
this sort of thing, or have the internal changes been large enough that
this too is no longer feasible.

> >  Also, I rely on them for a perl wrapper for
> > the library (http://sigcperl.sourceforge.net), which is used by the worldforge
> > project (http://www.worldforge.org) to provide perl bindings for its client
> > library. I use the macros to autogenerate wrappers for the autogenerated
> > signal classes.

And a mail from Martin on the same subject:

> 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, if
> > that would help, and I would accept a patch to do that. For instance,
> > 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 wrappers
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 letting
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, licensing
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 multiple
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.

Ron Steinke