Re: texinfo-6.7.90 tarball contains files that "make distclean" erases

[Bruno Haible]

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