Hi,
I've often wished that one could do:
---------------------------------
use Inline C => Config =>
WRITE_XS_FILE => 'My::Module';
use Inline C => <<'EOC';
// C code
EOC
# perl code
-------------------------------
And all that would do is create an XS file (in the cwd) that has set both
'MODULE = ' and 'PACKAGE = ' to the appropriate value.
I've oversimplified a little. I see that the line in C.pm that sets those
values is:
MODULE = $module PACKAGE = $pkg $prefix
so, apparently, the WRITE_XS_FILE argument needs to cater for the
possibility that $module and $pkg are different - whereas my simplistic
example has assumed they'll be the same. (At this point in time I don't
understand what $prefix is all about - I'd have to look into that.)
Is there any point in providing a patch that does this? Obviously, the
answer is "no" if:
a) Inline is never going to be updated;
or
b) such a patch is deemed undesirable, anyway.
I've written (and put on CPAN) Inline::C2XS, and whilst it does the job in
most cases, it is definitely breakable - and it's one of those
awful-half-arsed-inferior-wheel-re-invention-unmaintainable-type-of-modules
that we all (rightly) deplore.
A better solution would be to use Inline::C to do all of the XS file
creation (though that looks like being a bit of work). But an even *better*
solution, imho, would be if Inline::C provided that functionality, itself.
I have a bit of a thing against Inline::C-dependent modules on CPAN. I can't
get away from the feeling that if Inline::C had a user-friendly (and well
documented) c2xs() capability, then those modules on CPAN that *are*
dependent upon Inline::C would instead be appearing as normal CPAN distros
(not dependent upon Inline::C). We could have our Inline::C script that
tests out our functions for us, and when we're ready to upload to CPAN we
can just re-run the script with WRITE_XS_FILE config option set
appropriately ... and, voila! ... we have an XS file that we can bundle with
a normal Makefile.PL, MANIFEST, etc and put on CPAN. And users can build and
use that module without having to first install Inline::C ... and PAR will
be able to properly handle scripts that use that module (which is not the
case with modules that are dependent upon Inline::C).
Anyone who looks at Inline::C2XS will probably decide that it's not a good
idea to have *me* provide the proposed patch. I have absolutely no
objection to someone else providing it :-)
Anyway, I'm basically just trying to work out which way to go with this. Do
I persevere with Inline::C2XS along its current lines ? or do I rewrite
Inline::C2XS so that it use Inline::C to write the XS file ? or do I provide
a patch to Inline/Inline::C ? or do I just forget about the whole issue ?
Cheers,
Rob
