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: C:/Temp/ghc1596_0/ghc1596_0.lpp:1: warning: universal character names are only valid in C++ and C99 C:/Temp/ghc1596_0/ghc1596_0.lpp:1: incomplete universal character name \u The problem can be fixed by not using platformPath in parseFilePathQ. See the comments in GHC's DriverPipeline.hs, lines 1364-1372: -- 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. Regards, Brian On 10/7/06, Duncan Coutts wrote:

Hi all,

I've put up a tarball for the fourth 1.16 Cabal release candidate:

http://www.haskell.org/cabal/release/cabal-1.1.5.9.4/cabal-1.1.5.9.4.tar.gz

I had been hoping that this would be the final RC. One bug I've uncovered is that building the haddock docs for HUnit when cpphs is installed fails. This is because the Distribution.PreProcess.Unlit.unlit code produces incorrect output for Test/HUnit/Lang.lhs.

I could do with some help in fixing this.

One can reproduce it with:

cd libraries/HUnit cpphs -OLang.lhs Test/HUnit/Lang.lhs --noline --strip -D__GLASGOW_HASKELL__=605 -D__HADDOCK__ ghc -e 'interact (Distribution.PreProcess.Unlit.unlit "Lang.lhs")' < Lang.lhs > Lang.hs

compare this with:

ghc -E Lang.lhs -o Lang.hspp

and try:

diff Lang.hspp Lang.hs

Cabal's unlit code is incorrectly dropping whitespace and actual tokens. See especially the last part of that file.

I think this needs fixing asap since the cpphs code path gets used in preference to the ghc -E path if cpphs is installed. In this example the symptoms are not too bad as it seems only to be affecting haddock, but I fear it may break more seriously in other packages.

Duncan

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

On 10/7/06, Duncan Coutts wrote:

Hi all,

I've put up a tarball for the fourth 1.16 Cabal release candidate:

http://www.haskell.org/cabal/release/cabal-1.1.5.9.4/cabal-1.1.5.9.4.tar.gz

When a Cabal file is created on Windows, with Windows line endings \r\n, and it is then used on Linux, Cabal generates executables with file names that have a carriage return. For example, Executable: executable-name The Windows file name is correctly executable-name.exe, but on Linux it becomes executable-name^M. A workaround is to strip the carriage returns from the file. Regards, Brian