make check on Windows (MSYS), with patch

I have attached a patch that allows "make check" run more or less successfully on Windows. The patch converts Windows-style newlines to Unix-style newlines from the output of the test, so that when the actual output is compared to the expected output, the newline differences don't set off false positives. It also fixes a couple obvious problems with the tests to make them work on MSYS. I have also attached the results of "make check." I went through all the failures and gave some notes below. ./../src/hugs +q -w -pHugs: static/mod154.hs < nul This seems to be a known bug in Hugs since mod154.hs says "Hugs gets this wrong." ./../src/hugs +q -w -pHugs: rts/read.hs < rts/read.input The exponents on floating point numbers include an extra leading "0": "-3.10862446895044e-015" instead of "-3.10862446895044e-15" and "2.384186e-007" instead of "2.384186e-07". GHCi strips all the leading zeros from the exponents in both cases. So, there is a bug in the tests (doesn't properly take leading zeros into account in exponents) and/or Hugs (if the Haskell spec. requires leading zeros to be stripped like GHCi does). ./../src/hugs +q -w -pHugs: rts/arith.hs < rts/arith.input There is a difference "-0" vs. "0" that seems not totally unreasonable. The other difference "inf" vs. "1.#INF" seems like a bug in Hugs. ./../src/hugs +q -w -pHugs: ffi/Sin.hs < ffi/Sin.input The unexpected signal is troubling, but I don't know what the problem is. ./../src/hugs +q -w -pHugs: ffi/FileIO.hs < ffi/FileIO.input The unexpected error seems to be caused by the fact that "/tmp/test_write" is being opened, when this file doesn't exist normally on Windows. This is a bug in the test. ./../src/hugs +q -w -pHugs: ffi/Sparc.hs < ffi/Sparc.input I have no idea what is wrong. ./../src/ffihugs +q -w -pHugs: ffi/Callback.hs ffi/callback.c < nul This test assumes a case-sensitive file system that can distinguish between "Callback.c" and "callback.c." This test can be fixed by renaming "Callback.hs" to "CallbackTest.hs" and renaming callback.c to callback_c.c. Patch included, but you have to do the renaming of the file yourself. However, after getting it to build successfully, it still fails with output "unexpected signal" and exit code 1, and I have no idea why. ./../src/hugs +q -w -pHugs: System libs/system1.hs < libs/system1.input If I run this test directly it gives the expected output. But, inside of "make check" it fails because MSYS's SHELL is "sh.exe" instead of "sh." Patch included. ./../src/hugs +q -w -pHugs: Directory libs/dirTest.hs < libs/dirTest.input This test fails, but I think it is simply because NTFS doesn't support the same permission combinations as Unix/Linux. Either a Windows-specifc version should be written, or the test should be skipped on Windows.

On Thu, Jul 28, 2005 at 08:25:05PM -0500, Brian Smith wrote:
I have attached a patch that allows "make check" run more or less successfully on Windows. The patch converts Windows-style newlines to Unix-style newlines from the output of the test, so that when the actual output is compared to the expected output, the newline differences don't set off false positives. It also fixes a couple obvious problems with the tests to make them work on MSYS.
Thanks! I don't know how to strip CRs portably, but I've applied the rest.
I have also attached the results of "make check." I went through all the failures and gave some notes below.
./../src/hugs +q -w -pHugs: static/mod154.hs < nul
This seems to be a known bug in Hugs since mod154.hs says "Hugs gets this wrong."
Yes
./../src/hugs +q -w -pHugs: rts/read.hs < rts/read.input
The exponents on floating point numbers include an extra leading "0": "-3.10862446895044e-015" instead of "-3.10862446895044e-15" and "2.384186e-007" instead of "2.384186e-07". GHCi strips all the leading zeros from the exponents in both cases. So, there is a bug in the tests (doesn't properly take leading zeros into account in exponents) and/or Hugs (if the Haskell spec. requires leading zeros to be stripped like GHCi does).
Another known bug. GHC follows Haskell 98, which specifies the output precisely. Hugs uses the system's C library, which is both noncomformant to H98 and differs between systems.
./../src/hugs +q -w -pHugs: rts/arith.hs < rts/arith.input
There is a difference "-0" vs. "0" that seems not totally unreasonable. The other difference "inf" vs. "1.#INF" seems like a bug in Hugs.
Another C library difference.
./../src/hugs +q -w -pHugs: ffi/Sin.hs < ffi/Sin.input
The unexpected signal is troubling, but I don't know what the problem is.
Probably using ccall where Windows uses stdcall.
./../src/hugs +q -w -pHugs: ffi/FileIO.hs < ffi/FileIO.input
The unexpected error seems to be caused by the fact that "/tmp/test_write" is being opened, when this file doesn't exist normally on Windows. This is a bug in the test.
Fixed that, but the test will fail because of CR/LFs in the data.
./../src/hugs +q -w -pHugs: ffi/Sparc.hs < ffi/Sparc.input
I have no idea what is wrong.
./../src/ffihugs +q -w -pHugs: ffi/Callback.hs ffi/callback.c < nul
However, after getting it to build successfully, it still fails with output "unexpected signal" and exit code 1, and I have no idea why.
More ccall/stdcall, I hope.

Ross wrote:
Brian wrote:
I have attached a patch that allows "make check" run more or less successfully on Windows. The patch converts Windows-style newlines to Unix-style newlines from the output of the test, so that when the actual output is compared to the expected output, the newline differences don't set off false positives. It also fixes a couple obvious problems with the tests to make them work on MSYS.
Thanks! I don't know how to strip CRs portably, but I've applied the rest.
What do you mean by "portably?" Do you mean, you want it to work for non-GNU sed, or do you just mean that you want it to work on non-Windows systems? My goal in writing it was to have it work on all systems, even Unix and Linux where it is superfluous. I hardly know anything about sed; I just copied it out of one of the sed FAQS. But, I see no reason why it shouldn't work for any system with GNU sed. For non-GNU sed, maybe "sed 's/\r//" or "tr '\013' ''" or dos2unix will work instead? Anyway, the other parts of the patch are not useful without the newline patch because the newline problem causes every test to fail. - Brian

On Fri, Jul 29, 2005 at 06:17:59PM -0500, Brian Smith wrote:
Anyway, the other parts of the patch are not useful without the newline patch because the newline problem causes every test to fail.
On second thoughts, shouldn't you have CR's in all the text files if you've configured your CVS client properly?

On 7/30/05, Ross Paterson
On Fri, Jul 29, 2005 at 06:17:59PM -0500, Brian Smith wrote:
Anyway, the other parts of the patch are not useful without the newline patch because the newline problem causes every test to fail.
On second thoughts, shouldn't you have CR's in all the text files if you've configured your CVS client properly?
I think so, but "configure" and "xml2sgml" (and possibly other things) don't work correctly unless I use my CVS client's "Use Unix line endings" setting (I use TortoiseCVS). First, configure failed (I don't remember which step), and the only way I was able to solve it was by saving "configure.achttp://configure.ac" with Unix line endings (using Textpad). Then, sgml2xml failed, for the same reason. - Brian

On 7/30/05, Brian Smith
On 7/30/05, Ross Paterson
wrote: On Fri, Jul 29, 2005 at 06:17:59PM -0500, Brian Smith wrote:
Anyway, the other parts of the patch are not useful without the newline patch because the newline problem causes every test to fail.
On second thoughts, shouldn't you have CR's in all the text files if you've configured your CVS client properly?
I think so, but "configure" and "xml2sgml" (and possibly other things) don't work correctly unless I use my CVS client's "Use Unix line endings" setting (I use TortoiseCVS). First, configure failed (I don't remember which step), and the only way I was able to solve it was by saving "configure.achttp://configure.ac" with Unix line endings (using Textpad). Then, sgml2xml failed, for the same reason.
Ross, you were right--please back out my patch for runstdtest. I have included a patch to configure.ac http://configure.ac and a patch for the docs/user_guide/Makefile.in that fixes the issues with newline problems. That way, using a "Use Unix line endings" option is not necessary. autoconf that comes with msysDTK does not escape line endings correctly inside of AC_OUTPUT and AC_CHECK_HEADERS when the line endings contain carriage returns; for AC_OUTPUT, the config.status field gets screwed up, and for AC_CHECK_HEADERS, something else gets screwed up (but I didn't check exactly what). Also, MSYS's sed apparently does not like carriage returns in any scripts that it is passed with its "-f" option. So, I changed the user guide's Makefile.in http://Makefile.in so that it generates and uses a carriage-return-free xml2sgml script. - Brian

Ross and everybody,
My patch to docs/users_guide/Makefile.in never got checked in. Without this
patch, "make" fails when trying to build the documentation, and "make check"
fails before it runs the tests. Please apply this patch or suggest an
alternative solution.
Thanks,
Brian
On 7/31/05, Brian Smith
MSYS's sed apparently does not like carriage returns in any scripts that it is passed with its "-f" option. So, I changed the user guide's Makefile.in http://Makefile.in so that it generates and uses a carriage-return-free xml2sgml script.
- Brian
participants (2)
-
Brian Smith
-
Ross Paterson