Hi Gavin, Jacob, > > > > Also the files MiscXS.c, TestXS.c, XSParagraph.c were included in the > > > > tarball, although "make clean" or "make distclean" deletes them. There > > > > are two possible ways to fix this: > > > > > > I think option B below would be the safer one. We check for xsubpp with > > > AM_MISSING_PROG so don't currently require it to be available. > > > > I am fairly sure that any system with a perl capable of loading XS modules > > has a working xsubpp. > > > > As I understand, the .xs file is the proper source file and there are few, > > if any, guarantees that the generated .c file will work with any perl other > > than the one used to produce it. In other words, distributing the .c files > > xsubpp produces is pointless, as anyone who can use them will also have > > xsubpp to generate them and weird and bizarre bugs can occur if those files > > should have been regenerated with the local xsubpp but were taken as > > distributed for whatever reason. > > That's what you say, but I don't know if it is true. The fact is we > distributed > the .c file before and nobody reported any problems. That would be enough on > its own, but the "perlxs" manual has the following: > > Of course, one could write such glue code directly in C. However, this > would be a tedious task, especially if one needs to write glue for > multiple C functions, and/or one is not familiar enough with the Perl > stack discipline and other such arcana. XS comes to the rescue here: > instead of writing this glue C code in long-hand, one can write a more > concise short-hand description of what should be done by the glue, and > let the XS compiler xsubpp handle the rest. > > So I think is better to distribute the .c files unless there's good evidence > that it causes a problem somewhere.
When you look into the files MiscXS.c, TestXS.c, XSParagraph.c (search for PERL_VERSION in there) you can see that * The generated C code needs to be dependent on the Perl version, * xsubpp has produced code that is compatible with older Perl versions. So, if you produce the tarball with Perl version X and users have a version compatible to X or smaller than X, everything is fine. What is not covered is the forward compatibility: If you produce the tarball with a Perl version that exists today, and in two years the newest Perl requires different C code and thus the latest xsubpp generates PERL_VERSION conditionals to cope for this case, you get bug reports because the files that you have included in the tarball are incompatible. I would therefore follow Jacob's wisdom. Bruno
