Date: Thu, 28 Jun 2001 13:12:02 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
cc: djgpp-workers AT delorie DOT com, Laurynas Biveinis <lauras AT softhome DOT net>
Subject: Re: Build failure of CVS docs
In-Reply-To: <CAEGKOHJKAAFPKOCLHDIKENPCEAA.tim.van.holder@pandora.be>
Message-ID: <Pine.SUN.3.91.1010628131135.12284D-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Wed, 27 Jun 2001, Tim Van Holder wrote:

> Given that I committed those, I expect it's my fault; apparently
> I forgot to dtou them, so they got committed as DOS text.

If you use some CVS client that commits DOS text files without
stripping CR characters, you shouldn't have the CRs in the files to
begin with.  What editor do you use to create the files?  Does that
editor have an option to created Unix-style files?

> My guess is that your client translated the text file (LF->CRLF)
> when it was already DOS text (hence CRCRLF).

Unless the library build procedure is run on a Unix box in cross-build
environment, these extra CR characters shouldn't matter, since
makeinfo reads input in text mode, and our libc removes _all_ CR
characters, not just those before an LF.

That is why I didn't see the problem on my machine, although my CVS
client also adds CR to each LF.