Michael George wrote:
Name clashes were a concern in the past when extension modules were statically linked to the Python interpreter, as was necessary with DOS. I assume no modern operating system requires this, so name clashes are no longer an issue. (See below.) If anyone is still statically linking the Pygame extension modules they haven't complained about name conflicts yet. Besides, all the bitmask names are mangled with a prefix.The part I was and am still a bit confused about is name clashes. If I understand correctly, python extension modules are supposed to only export the initmodule method in order to avoid name clashes, which is why the docs say everything should be static. But if bitmask is linked in to the module, then won't it's functions be exported? If not, then is it possible for me to call them, or do I need to link bitmask into my code as well? And how is bitmask different than SDL in terms of how it's linked, if at all?
As to accessing the bitmask functions it depends on what you want. See below.
There is no difference between bitmask and SDL when it comes to name clashes. SDL function names are resolved by the linker at build time, just as with bitmask. SDL functions appear in the mask namespace just as bitmask functions do. See below.
Sorry, I feel like I'm saying a bunch of nonsense, but I'm having a hard time making sense of all this dynamic linking stuff.Shared (dynamic) libraries are somewhat like programs. Just as with a program, non-static functions and global variables can be local to the library. But where as a program has a single entry point, a main function, a shared library can have many. These are the exported functions and variables of the library. They form the API. Only these can be directly accessed by other programs or shared libraries. For Windows shared libraries (Dynamic Link Libraries or DLLs) the linker has to be told which non-static functions and global variables get exported. Everything else remains local to the DLL. For Unix shared libraries I believe all non-static functions and global variables are exported by default. I think gcc has ways around this though. But for Python extension modules this is not a problem.
There are two ways to use a shared library. The first is to load the library dynamically during program execution. Explicit system calls are made to load the library and get pointers to its exported functions and data. This is how the Python interpreter loads extension modules. No name conflicts between extension modules are possible in this case. The ctypes package, introduced in Python 2.5, wraps the dynamic load mechanism, so any shared library is accessible from within Python.
The second way to use a shared library is to have the program loader do the linking at startup. An import library, a proxy to the shared library, stands in for the library when building a program. The import library looks just like any static module. Exported functions and data look just like non-static functions and global variables to the program. So name clashes are possible with other non-static names in the program. Exported names are resolved dynamically at program load time rather than statically at build time. A shared library is loaded only once, when the first program that uses it is loaded. Other programs share the library's memory image. This is how mask and other Pygame extension modules link to SDL.
I don't suggest making bitmask a shared library. The only shared libraries Python's distutils knows how to build are extension modules.
What I'm doing now is adding a CObject to the mask module for the PyMask_Type, and then compiling my code against bitmask.h (which I'm leaving as-is) and mask.h (which looks like some of the other header files, and exports a C API with a bunch of #defines). So I'm assuming I'll need to use CObjects to get at stuff in mask.c (the Type in particular), but I can link directly to the stuff in bitmask.If you are just extending the mask module itself then the bitmask functions will be visible to your code. Just add any new C files to the mask entry in Setup.in. They will be compiled and linked to mask and bitmask automatically. Remember to run config.py after any changes to Setup.in. Name the non-static functions with a prefix like bitmap_. Any new Python functions go into mask.c itself and remain static.
If you are adding a new extension module then the simplest solution is to just include bitmask.c in that module as well. If you are concerned about name clashes then copy the bitmask.c file as bitmask2.c and rename the functions: bitmap2_* maybe. Also unused code can be removed. The third option is to do as you suggest and export pointers to mask's bitmask functions using the PyCObject mechanism.
On an unrelated note, I'm looking at font.h as an example for exporting the api, and I was wondering in the import_pygame_font why the code does a memcpy instead of just changing the PyFONT_C_API pointer. Isn't there a danger of the memcpy stomping on something else, since it's copying 3 things into a 1-element array?PyFONT_C_API is an array of PYGAMEAPI_FONT_NUMSLOT, or 3, void pointers. The {NULL} initializer is valid for C99 and makes all array entries NULL. For C90 I don't know, but suspect it is invalid.
Lenard Lindstrom wrote:Hi Michael,bitmask.c is statically linked to mask.c as an object file. On Windows the distutils package ensures only the initmask function is exported as an entry point into the mask.pyd DLL. Unix dynamic libraries may be more liberal as to what is exported, but Python will only directly call the module initialization function, so no problem.Setup.in controls extension builds. This is like a make file. Each extension module, like mask, has its own line, or dependency entry. A new C module can be added to an extension module by adding its source file to an extension module entry. Be sure to run config.py afterward to build the Setup file used by setup.py.Lenard Michael George wrote:Greetings,[snip]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?[from another post in this thread] > > Understanding the build system(s) is a bit daunting.
-- Lenard Lindstrom <len-l@xxxxxxxxx>