Eli Zaretskii writes:
> > From: Paul Smith <psm...@gnu.org>
> > Date: Wed, 31 May 2017 19:48:57 -0400
> >
> > I'm working on ensuring that the test suite works on Windows
>
> That's great news, thanks!
>
> > #if !defined(WINDOWS32) && !defined(__MSDOS__) && !defined(__EMX__)
> > /* Check to see if the line was really ended with CRLF; if so
> > ignore
> > the CR. */
> > if ((p - start) > 1 && p[-2] == '\r')
> > {
> > --p;
> > memmove (p-1, p, strlen (p) + 1);
> > }
> > #endif
> >
> > I'm not sure about this implementation (performance-wise) but leaving
> > that aside, I don't understand why this code is ifdef'd out on Windows.
>
> Well, it's your code, or so it seems ;-) And it was always ifdef'ed
> away on those platforms, since the day it was committed back in 1999
> (see commit 7052a57).
>
> > I mean, CRLF is more prevalent on Windows so why wouldn't we have this
> > there?
> >
> > Is the idea that on Windows we want to preserve the CRLF, for some
> > reason? I'm not sure I see the point in doing that when we're parsing
> > the makefile; I mean we'd throw away all the newlines on UNIX, so why
> > would we preserve the CRLF on Windows?
>
> I think Ray is right: the CRLF combination simply cannot happen on
> those platforms, because Make there uses text-mode reads, so the CR
> characters are simply gone by the time we get here.
I concur that the code is disabled on Windows due to text mode
stripping away the '\r' and leaving only '\n' in the input stream.
I surmise it's enabled on non-Windows builds to allow them to work
wtih Makefiles created on a Windows machine.
thutt
--
What books will be in the Trump Presidential Library?
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
