Cabal eats leading '.'s from .cabal file

[igloo@…]

In this cabal file:

name: foo
version: 1
exposed-modules: Foo
build-depends: base
include-dirs:
    ../includes

Cabal is eating the leading . resulting in -I./includes:

$ ./Setup build -v
Preprocessing library foo-1...
Building foo-1...
/usr/bin/ghc -package-name foo-1 --make -hide-all-packages -i -idist/build/autogen -i. -I./includes -odir dist/build -hidir dist/build -package base-2.0 Foo
/usr/bin/ar q dist/build/libHSfoo-1.a dist/build/Foo.o
/usr/bin/ar: creating dist/build/libHSfoo-1.a
/usr/bin/ld -r -x -o dist/build/HSfoo-1.o.tmp dist/build/Foo.o

I think this is so you can give a description like

Paragraph 1
.
Paragraph 2

with the '.' being removed, but it is being applied too liberally. I would also expect a '.' to be removed only if it is the only (non-white) character on a line.

The relevant code is

merge :: [(a, [Char])] -> [(a, [Char])]
merge ((n,x):(_,c:s):ys)
  | c == ' ' || c == '\t' = case dropWhile isSpace s of
                               ('.':s') -> merge ((n,x++"\n"++s'):ys)
                               s'       -> merge ((n,x++"\n"++s'):ys)
merge ((n,x):ys) = (n,x) : merge ys
merge []         = []

in ParseUtils.hs, called from readFields.

[ross@…]

Fixed in HEAD and ghc-6.6 by the following patch:

Sun Mar 11 15:46:10 GMT 2007  Ross Paterson <ross@soi.city.ac.uk>
  * rejig handling of continuation lines (fixes Cabal #118)
  
  Also avoids quadratic behaviour on long fields.

[duncan]

Yes, this is bad. It just bit me too in HEAD. I was using:

Library {

include-dirs: .

}

and that gets striped to nothing, which means we pass "-I" to ghc with no following path (which makes ghc complain).

[nominolo]

The "." -> "" problem is a problem in filepath, not necessarily Cabal. The problem is that it calls normalize which does this (IMO) illegal transformation. A normalized path should always work. I think Neil fixed this in the latest (unreleased) filepath, I haven't tested though. The problem described in the original report should be fixed, though it's sad we do not seem to have regression tests for this one.

[duncan]

Now fixed by not using normalize in a few places.

[guest]

Fixed in filepath 1.2