On Jan 5, 2007, at 4:38 PM, drieux, just drieux wrote:
most libraries are built up from a collection of *.c files,
and then built into a single library.... so that part is
clearly doable - but are you using the Build based
tools? or the standard h2xs tools???
The distro uses Module::Build -- actually a heavily customized
subclass, but by the time we get to the "./Build code" action,
everything looks like a normal XS distro, with 1 XS file, a couple
hundred .c/.h files, and around 100 Perl modules. Module::Build is
already being smart about conditionally compiling the supplied .c/.h
files. I believe it's using its own up_to_date() function against
the object files to determine which .c files need recompilation.
However, the problem is the one .c file which is generated by the XS-
to-C compiler, either xsubpp or its modularized wrapper
ExtUtils::ParseXS.
I suppose I should go spelunk the "code" action in Module::Build, and
see if following that thread leads me anywhere interesting.
However, I suspect that xsubpp/ExtUtils::ParseXS won't be able to
handle multiple XS files for the same MODULE, regardless. I believe
this because at the end of the generated C file I find a boot
function called "XS(boot_KinoSearch)", and I'm guessing that you get
one of those for every MODULE you specify. If I supply multiple XS
files -- KinoSearch/Analysis.xs, KinoSearch/Search.xs, etc -- but do
what I'm doing now and always set MODULE to "KinoSearch" regardless
of PACKAGE, e.g...
MODULE = KinoSearch PACKAGE = KinoSearch::Analysis::Tokenizer
... I'll bet we'll end up with several conflicting definitions for "XS
(boot_KinoSearch)". Looking at the docs for xsubpp, I don't see a
way to stop it from generating that boot function.
Let's say that instead of 1 XS file with 1 MODULE and many PACKAGEs,
I supply an XS file for each of the 50 or so XS packages in
KinoSearch. I think that means we'll get 50 shared libraries... and
they'll all have to be linked against my C sources. The default
seems to be static linking, which means that the object code output
from my .c/.h sources would get duplicated 50 times.
One way to avoid that duplication would be to compile an external
shared library built up from my C source files, and put it in a
location like /usr/local/lib. Then each of the 50 XS libraries could
link against it dynamically. However, I'm more inclined to keep the
system I have now, where there's only one shared object with
everything in it. I'd just like to be able to build that up bit by
bit, conditionally compiling not only my supplied C source files, but
also the C code generated by xsubpp.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
