Python modules written in C are often written as single .c files
(sometimes quite large) so that everything can be declared "static"
except for the init<module>() function; and though the Extending and
Embedding document is unfortunately rather quiet on the many issues
that arise during linking, the suggestion seems to be that minimizing
the number of symbols exported by the module is good.
As I update a Python module that provides an interface to an extensive
collection of existing C functions, I note that the process of linking
my module .o with all of the .o files produced by compiling the other
code produces a Python module with a huge number of symbols.
1) Is this bad and should be avoided?
I note that running strip(1) with the "-K" option allows me to strip
all defined symbols from the module except for the one init<module>
symbol that I want to keep.
2) Do the distutils know how to perform this operation? This would
even allow Python modules to be written as several manageable .c
files rather than one huge one.
3) Can the distutils be induced to perform such a strip even if they
do not quite know how themselves, or is the whole issue going to
be different enough on, say, Windows, that it cannot be handled
portably with the distutils in their current form?
--
Brandon Craig Rhodes br*****@rhodesmill.org http://rhodesmill.org/brandon
