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

On 2012-10-05 18:03, Gary V. Vaughan wrote:
> 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.

Others have answered this, so I will stop at mentioning that it would be
fantastic if you could run smoke tests on MSYS/MinGW before commit!
The worst case is MSYS/MSVC I think, but I don't mind if you skip that.
Covering MSYS/MinGW would be plenty enough.

> On 5 Oct 2012, at 22:21, Peter Rosin <[email protected]> wrote:
>>> 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]]

Pushed with this ChangeLog

	tests: fix line ending problems on MinGW

	* tests/cdemo.at: Use LT_AT_HOST_DATA for expected output from
	compiled programs.
	* tests/demo.at: Likewise.
	* tests/depdemo.at: Likewise.
	* tests/f77demo.at: Likewise.
	* tests/fcdemo.at: Likewise.
	* tests/mdemo.at: Likewise.
	* tests/tagdemo.at: Likewise.

	Signed-off-by: Peter Rosin <[email protected]>


> 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)

After hiding $0 from m4 with [$]0, it resolved the whitespace issues
I think. I pushed a patch with that m4-escape folded in.

	tests: make LT_AT_HOST_DATA retain whitespace on MinGW

	Fixes issues with depdemo.at, f77demo.at and fcdemo.at.

	* tests/testsuite.at (LT_AT_HOST_DATA) [MinGW]: Keep leading
	and trailing spaces and tabs when converting line endings.
---
 tests/testsuite.at |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/tests/testsuite.at b/tests/testsuite.at
index 60ff5d5..2a55d04 100644
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -256,8 +256,7 @@ AT_CHECK([test -z "$leftovers"])
 m4_define([LT_AT_HOST_DATA],
 [AT_DATA([$1], [$2])
 case $host_os in mingw*)
-  while read -r l; do printf "%s\r\n" "$l"; done < $1 > $1.t
-  mv -f $1.t $1 ;;
+  awk '{printf ("%s\r\n", [$]0);}' < $1 > $1.t && mv -f $1.t $1 ;;
 esac])
 
 

> 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.

Done.

The remaining fallout is libtool.at, mdemo.at, f77demo.at and fcdemo.at.
I'll see what I can dig out...

Cheers,
Peter