4th Cabal-1.1.6 release candiate

[Brian Smith]

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 <duncan.coutts at worc.ox.ac.uk> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20061007/827ced36/attachment.htm