Hi,
Maybe submit your extensions for inclusion? That might be the
easiest. What extensions are they?
It'd be nice for any fix ups to mask... it's got a few issues.
However making a C API for it is not a priority at the moment...
Marcus has done some work on it for pgreloaded (see a branch in svn).
http://www.seul.org/viewcvs/viewcvs.cgi/branches/pgreloaded/src/mask/?root=PyGame
If you'd like to submit changes for making a C API similar to how it's
done in pygame for other modules, that'd be cool too.
An issue with making functions static is that then they can have
issues being multi threaded if they release the python GIL.
... so I think it'd be best to submit your extensions into pygame I
think. Since there's no real C API at the moment. Then we can make
sure your extensions are in pyreloaded too.
cheers,
On Wed, Dec 3, 2008 at 12:36 PM, Michael George <mdgeorge@xxxxxxxxxxxxxx> wrote:
Greetings,
I have some extensions to the mask module for my game, and I'm trying to
figure out how to build/package them. For the sake of getting it working
I've just hacked them into the pygame source and been building a custom
pygame, but obviously that's not a good solution.
However as I'm trying to tease it out of there I'm coming across some
confusion. It looks to me like the mask module violates the "everything
static except initmodule" rule, because the functions in bitmask.c are
exported, and AFAICT bitmask.c is linked into the mask module.
Part of the reason this is a problem is because the mask module doesn't seem
to export any kind of C API like the other modules do. It would be useful
to me if the bitmask_* functions were exported.
I'd be happy to spend some time and submit a patch, but I'm not quite sure
how it should work. Should mask.c access the bitmask.c functions through
the exported function table? Should mask.c just #include bitmask.c? Any
thoughts?
--Mike