Windows Line Endings [WAS Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183]

[Gary V. Vaughan]

Hi Peter,

Apologies for having entirely forgotten about the old thread reviewing
those patches first time around.

And thanks for looking into it.  Is there a legal way to get access
to Windows and the various flavours of gcc and MSVC that libtool users
care about, without spending hundreds of dollars on software I would
never use for anything else?  It pretty much sucks that everytime I
push a well tested (on various Unix varieties) patch, that Windows likes
to blow up gratuitously.  I don't mind wasting a bit of time checking
things on Windows, but I really don't want to also waste money on
Microsoft.

On 5 Oct 2012, at 22:21, Peter Rosin <address@hidden> wrote:

>> The above looks just like a classic Windows failure. I.e. a line
>> ending mismatch between the expout file created by the posixy
>> shell (\n) and the Win32 program (\r\n) and I would guess that
>> this is a problem that caused failures for Chuck last year as
>> well.
>> 
>> I think you need to use LT_AT_HOST_DATA instead of AT_DATA, where
>> appropriate.
> 
> Unfortunately, the below is not enough since LT_AT_HOST_DATA
> eats whitespace ("  foo" -> "foo") which affects depdemo.at,
> f77demo.at and fcdemo.at. mdemo.at also seems to have
> more trouble that I need to look into...

[[Patch snipped]]

I appear to have arrived at the same patch, and it still passes
make distcheck on Mac OS X.  So LT_AT_HOST_DATA must only eat
whitespace on Windows?  So the fix must be in the windows loop to
rewrite lines with \r\n.  What's wrong with using awk or sed to
inject the additional character rather than shell?  That would seem
to be the obvious solution to me:

  awk '{printf ("%s\r\n", $0);}' < $1 > $1.t && mv -f $1.t $1

(untested on Windows, but doesn't mess with whitespace on Mac or Linux)

Please do push patches that improve the situation for Windows rather
than holding out for a fix-all mega-patch.  This will allow us to
keep each other informed of breakages on platforms the other doesn't
have access to.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)