Twan van Laarhoven wrote:
I am having some problems with the latest builds of GHC on windows. For some reason ghc has decided to use backslashes in filenames. This leads to problems when building the stage libraries and the stage 2 compiler. I run the scripts from a mingw bash shell.
After further investigation, it seems the problems are caused by using () instead of joinFileName. These functions differ in two ways: 1. "." as a directory name is no longer ignored "." "x" == "./x" /= "x" == "." `joinFileName` "x" this (among other things) changes compiler messages: -[1 of 4] Compiling OverA ( OverA.hs, OverA.o ) -[2 of 4] Compiling OverB ( OverB.hs, OverB.o ) -[3 of 4] Compiling OverC ( OverC.hs, OverC.o ) +[1 of 4] Compiling OverA ( .\OverA.hs, .\OverA.o ) +[2 of 4] Compiling OverB ( .\OverB.hs, .\OverB.o ) +[3 of 4] Compiling OverC ( .\OverC.hs, .\OverC.o ) 2. a backslash is used on windows instead of a slash. Some things explicitly exect a slash to be used on windows as well: a. main/DriverPipeline.hs:1511: -- We hackily use Option instead of FileOption here, so that the file -- name is not back-slashed on Windows. cpp is capable of -- dealing with / in filenames, so it works fine. Furthermore -- if we put in backslashes, cpp outputs #line directives -- with *double* backslashes. And that in turn means that -- our error messages get double backslashes in them. -- In due course we should arrange that the lexer deals -- with these \\ escapes properly. b. gnu make wants slashes, filenames containing backslashes are outputed through DriverMkDepend. 1 is a minor problem it just requires some test cases to be changed. On the other hand, adding "./" everywhere is needless clutter. 2a results in some warnings, 2b is a big problem, breaking the build on windows. The only good solution I see is to switch back to joinFileName or an equivalent function. Twan