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

[Gavin Smith]

On 27 September 2015 at 19:34, Vincent Belaïche <address@hidden> wrote:
> I just realized that we have already discussed this sort of EOL conversion in
> relation with [bug #38795]. In [bug #38795] my problem was that the BBDB
> manual was made of several files, some of them had svn:eol-style set to LF and
> others to native becoming CRLF for MSW users, so when compiling the source
> with makeinfo I also had inconsistent EOL's in the output.
>
> I try to summarize the discussion that had happened below:
>
> * Patrice said there was not any intention to make any EOL conversion, and if
> it happens, it is by accident (cf 2013-04/msg00016
> <http://lists.gnu.org/archive/html/bug-texinfo/2013-04/msg00016.html>)
>
> * Karl (cf 2013-04/msg00020
> <http://lists.gnu.org/archive/html/bug-texinfo/2013-04/msg00020.html> said
> that Texinfo should not canonicalize the input EOL's, but the user has to use
> input files and tools with consistent EOL style, so this was a bug in BBDB
> manual version control, they should have had the same eol-style property
>
> * Eli said CRLF EOL must be supported on MSW (cf 2013-04/msg00017
> <http://lists.gnu.org/archive/html/bug-texinfo/2013-04/msg00017.html>), my
> understanding that LF only was to be used was based on a misleading doc which
> has probably been corrected since then.
>
> So in a nutshell, the consensus that was to use tools with EOL-style
> consistent with the input files. This was against my opinion that either some
> input EOL canonicalization has to be done by Texinfo tools, or Texinfo source
> code should use only LF.

Thanks for the summary.

>
> Then, with this consensus which seemingly has not changed, I am wondering how
> it can work in the following situation:
>
> * 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.

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. 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.

> 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.

> 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?