Re: [bug #46018] texi2any makes inconsistent EOL style

[Eli Zaretskii]

> Date: Sun, 27 Sep 2015 21:12:17 +0100
> From: Gavin Smith <address@hidden>
> Cc: Eli Zaretskii <address@hidden>, Vincent Belaïche <address@hidden>, 
>       Texinfo <address@hidden>
> 
> > * I get some Texinfo source code from project A, and project A people have
> > decided to set svn:eol-style to LF for Texinfo files, so I am supposed to
> > compile thes files with MSYS perl, the output file will be in LF, so their
> > svn:eol-style need to be also set to LF.
> >
> > * I get some Texinfo source code from project B, and project B people have
> > decided to set svn:eol-style to native for Texinfo files, so I am supposed 
> > to
> > compile thes files with native perl. The output files will be in native 
> > (CRLF
> > on MSW), so their svn:eol-style need to be also set to LF.
> >
> > * I could also use a native perl to compile files with LF EOL's, the output
> > will have consistent CRLF EOL's, so that will raise some problem if it is
> > version controlled and has, like input svn:eol-style set to LF
> 
> What I think is missing here is that the files in the project are also
> distributed outside of SVN or any other version control system that
> could cause EOL conversion. Those files could have LF line endings, or
> CR-LF line endings.

Yes.  But a project/user receiving Texinfo sources with CRLF EOLs
could easily process it with 'flip' or 'dos2unix' to remove the CR
characters.  That's the easiest way of avoiding the problems caused by
the EOL format altogether.

> LF line endings are what we would recommend in a Texinfo file that is
> being distributed, as this is the native line ending for GNU systems.
> Therefore programs processing Texinfo files on Windows (texi2any)
> should also cope with LF line endings. They may or may not cope with
> CR-LF line endings as well.

Native Windows programs will always cope, as they use text-mode I/O
that strips CR characters on input.

> Since people downloading Texinfo files via SVN are likely to process
> them with the same tools as they use to process Texinfo files found
> in e.g. a *.tar.gz distribution file, it follows that the SVN
> repositories should also be set up to transmit the files with LF
> line endings.

Agreed.

> > In conclusion, if I want to work both on project A and project B, I need two
> > texi2any wrappers, one using MSYS perl for project A, and one using native
> > perl for project B. This is not very practical.
> 
> I'd recommend using whichever perl version for which texi2any can
> process input files with LF line endings. In case the _output_ files
> have a different line ending type to the one you want, I have nothing
> to suggest, other than using some way of converting the files
> automatically. Possibly both of those versions of perl you've
> mentioned would work.

Relevant programs on modern Windows systems can handle text files with
Unix-style EOLs just fine.  Even Notepad can do this nowadays, to say
nothing of Emacs, the stand-alone Info reader, and any decent HTML
browser.

So keeping the Texinfo output files in Unix-style LF-only format is
what I would recommend.

> > Please note that I am not even sure that it is possible to install texi2any 
> > on
> > MSW with a native perl, as far as the installation scripts are MSYS based. 
> > In
> > fact, I am using a non installed texi2any with interpreting the perl code in
> > its source directory either with a native perl or an MSYS perl. Using a non
> > installed texi2any raises some problem for the locales ; but that is another
> > issue.
> 
> Don't understand this. The installation is done by a standard build
> system generated by Automake. Why would it matter if it was
> interpreted by MSYS tools?

It doesn't matter.  It's certainly possible.  All it needs is specify
an explicit 'prefix' at "make install" time:

  make install prefix=/usr/local

Note, however, that the version of Perl distributed with some MSYS
packages is quite old.  For example, mine is this:

  $ perl --version

  This is perl, v5.8.8 built for msys-64int

  Copyright 1987-2006, Larry Wall

Such old versions will typically emit warnings, and might even fail,
when invoked by texi2any.  So my suggestion is to pair texi2any with
the native Perl, which can be upgraded to a new enough version, unlike
MSYS whose development stopped, and where replacing Perl might cause
the entire suite of tools to become fragile due to incompatibilities.