If hs-source-files contains a path with that contains slashes "some/utils," and Extensions: CPP is used, and you compile a lhs file with GHC 6.5 RC2, on Windows, then GHC will generate a lpp file that contains .e.g. "#line 1 "some\utils/Maybes.lhs", and then CPP complains:
<br><br>C:/Temp/ghc1596_0/ghc1596_0.lpp:1: warning: universal character names are only valid in C++ and C99<br>C:/Temp/ghc1596_0/ghc1596_0.lpp:1: incomplete universal character name \u<br><br>The problem can be fixed by not using platformPath in parseFilePathQ.
<br><br>See the comments in GHC's DriverPipeline.hs, lines 1364-1372:<br><br> -- We hackily use Option instead of FileOption here, so that the file<br> -- name is not back-slashed on Windows. cpp is capable of<br> -- dealing with / in filenames, so it works fine. Furthermore
<br> -- if we put in backslashes, cpp outputs #line directives<br> -- with *double* backslashes. And that in turn means that<br> -- our error messages get double backslashes in them.<br> -- In due course we should arrange that the lexer deals
<br> -- with these \\ escapes properly.<br><br>
Regards,<br>Brian<br><br><div><span class="gmail_quote">On 10/7/06, <b class="gmail_sendername">Duncan Coutts</b> <<a href="mailto:duncan.coutts@worc.ox.ac.uk">duncan.coutts@worc.ox.ac.uk</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br><br>I've put up a tarball for the fourth 1.16 Cabal release candidate:<br><br><a href="http://www.haskell.org/cabal/release/cabal-1.1.5.9.4/cabal-1.1.5.9.4.tar.gz">http://www.haskell.org/cabal/release/cabal-1.1.5.9.4/cabal-1.1.5.9.4.tar.gz
</a><br><br><br>I had been hoping that this would be the final RC. One bug I've<br>uncovered is that building the haddock docs for HUnit when cpphs is<br>installed fails. This is because the Distribution.PreProcess.Unlit.unlit
<br>code produces incorrect output for Test/HUnit/Lang.lhs.<br><br>I could do with some help in fixing this.<br><br>One can reproduce it with:<br><br>cd libraries/HUnit<br>cpphs -OLang.lhs Test/HUnit/Lang.lhs --noline --strip
<br>-D__GLASGOW_HASKELL__=605 -D__HADDOCK__<br>ghc -e 'interact (Distribution.PreProcess.Unlit.unlit "Lang.lhs")' <<br>Lang.lhs > Lang.hs<br><br>compare this with:<br><br>ghc -E Lang.lhs -o Lang.hspp<br><br>
and try:<br><br>diff Lang.hspp Lang.hs<br><br>Cabal's unlit code is incorrectly dropping whitespace and actual tokens.<br>See especially the last part of that file.<br><br>I think this needs fixing asap since the cpphs code path gets used in
<br>preference to the ghc -E path if cpphs is installed. In this example the<br>symptoms are not too bad as it seems only to be affecting haddock, but I<br>fear it may break more seriously in other packages.<br><br>Duncan
<br><br>_______________________________________________<br>cabal-devel mailing list<br><a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/cabal-devel">
http://www.haskell.org/mailman/listinfo/cabal-devel</a><br></blockquote></div><br>