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 <p...@lysator.liu.se> 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 <p...@lysator.liu.se>
> 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
