Re: munge-texi.pl

[Rik]

On 01/05/2013 10:00 AM, address@hidden wrote:
> Message: 6
> Date: Sat, 5 Jan 2013 12:47:06 -0500
> From: Michael Goffioul <address@hidden>
> To: "John W. Eaton" <address@hidden>
> Cc: octave maintainers mailing list <address@hidden>
> Subject: Re: Octave 3.6.4-rc1 release candidate available for ftp
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Jan 3, 2013 at 4:04 PM, John W. Eaton <address@hidden> wrote:
>
>> > The second release candidate of Octave 3.6.4 is now available from
>> > alpha.gnu.org in the directory /gnu/octave:
>> >
>> >   a8261dbeb3fa23c575c5c905c6770cc0  octave-3.6.4-rc1.tar.gz  (md5sum)
>> >
>> >   -rw-r--r-- 1 3003 3002 18352066 Jan 03 20:36 octave-3.6.4-rc1.tar.gz
>> >
>> > Please help make the 3.6.4 release a success by building from this
>> > release candidate and reporting any problems.  We could especially use
>> > reports for Windows and OS X systems.
>> >
> Code compiles fine, but I've a problem rebuilding the doc (because of the
> patch I apply, some files are regenerated). I think it's due to the move of
> munge-texi from C++ to Perl. The file src/DOCSTRINGS is still generated by
> C++ and it uses the CRLF newline convention. However, munge-texi.pl does
> not chomp the CR character, so when reading src/DOCSTRINGS, it records
> symbols as "bitand<CR>" instead of "bitand" and then fails to match them
> when referenced in .texi files.
>
> I can find a local workaround for that, but I thought it's was worth
> mentioning.
>
> The problem does not occur in default branch, most probably because
> DOCSTRINGS generation has also been moved to Perl.
1/5/12

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?

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?

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

We could always use regular expressions in munge.texi to strip all space
characters from the end of line.

--Rik
>
> Michael.

tst_eol.txt
Description: Text document