There are a number of problems here. First, I made the change that
introduced munge-texi.pl and I have no memory of making it on the stable
branch. Touching the build process in this way seems mildly risky and it
surprises me that I would have done this. Is it possible that some
Mercurial shenanigans accidentally transplanted the patches from one branch
to another?
I suppose you already figured it out, but here it is:
One possibility, therefore, might be to transplant these changesets to the
default branch and use C++ generation of documentation for the 3.6.X
branch. Incidentally, the changes came in after the 3.6.1 release. Is
there any reason you haven't seen this trouble for the 3.6.2 and 3.6.3
releases? Or maybe you didn't bother to try compiling those with MSVC?
I didn't build 3.6.3, but did it for 3.6.2. Though I don't remember having that issue at the time.
Finally, I specifically used chomp() in Perl to handle EOL issues. On an
old Windows XP system, a text file is generated with "\r\n" as the line
ending but when I read that same file with Perl it auto-converts the line
to end in "\n". Maybe you can check what Perl does for you with the
attached tst_eol.txt file.
Try
perl -ne "print length ($_),\"\n\"; print ord (substr ($_,3))" tst_eol.txt
I get
4
10
My system says:
5
13
I'm using perl-5.8.8 under MSYS (obtained through mingw-get).
We could always use regular expressions in munge.texi to strip all space
characters from the end of line.
As an easy local workaround, I just added this line after opening the DOCSTRING file:
binmode DOCFH, ":crlf";
This enables CRLF conversion and solves the problem. Not very clean, but I can live with it.
Michael.