4th Cabal-1.1.6 release candiate

older
darcs patch: Inline shift in GHC's...

Duncan Coutts

7 Oct 2006 7 Oct '06

2:08 p.m.

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

Show replies by date

Malcolm Wallace

9 Oct 9 Oct

7:33 a.m.

Duncan Coutts wrote:

...

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.

You could try using the --unlit option of cpphs, which gives correct output, instead of the broken code in Distribution.PreProcess.Unlit.unlit. This requires cpphs >= 1.2, which was released in May this year. Regards, Malcolm

Duncan Coutts

1:59 p.m.

On Mon, 2006-10-09 at 12:33 +0100, Malcolm Wallace wrote:

...

Duncan Coutts wrote:

...
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.

You could try using the --unlit option of cpphs,

That sounds like a good plan.

...

which gives correct output, instead of the broken code in Distribution.PreProcess.Unlit.unlit.

I think the Distribution.PreProcess.Unlit module was taken from an early version of cpphs. One possibility would be to update to the latest cpphs unlit code, but for that of course we'd need your permission as the copyright licenses are different.

...

This requires cpphs >= 1.2, which was released in May this year.

Is there anyway to identify the cpphs version from running it? I don't see any --version flag or similar. I'm wondering how cabal is going to be able to identify if the user has a sufficiently recent version. Duncan

Malcolm Wallace

3:34 p.m.

Duncan Coutts writes:

...

...
...
I could do with some help in fixing this.

You could try using the --unlit option of cpphs,

I think the Distribution.PreProcess.Unlit module was taken from an early version of cpphs.

Probably it came from hmake, whose version of Unlit strips leading whitespace for the purpose of recognising import statements (to make them begin at column 0). Better to steal the version from nhc98 or cpphs, which does not strip whitespace.

...

One possibility would be to update to the latest cpphs unlit code, but for that of course we'd need your permission as the copyright licenses are different.

The unlit code in cpphs was largely taken from an early version of the Haskell Report.

...

Is there anyway to identify the cpphs version from running it? I don't see any --version flag or similar.

cpphs --version exists, and is documented. Regards, Malcolm

Duncan Coutts

3:57 p.m.

On Mon, 2006-10-09 at 20:34 +0100, Malcolm Wallace wrote:

...

Duncan Coutts writes:

...
...
...
I could do with some help in fixing this.

You could try using the --unlit option of cpphs,

I think the Distribution.PreProcess.Unlit module was taken from an early version of cpphs.

Probably it came from hmake, whose version of Unlit strips leading whitespace for the purpose of recognising import statements (to make them begin at column 0). Better to steal the version from nhc98 or cpphs, which does not strip whitespace.

Right.

...

...
One possibility would be to update to the latest cpphs unlit code, but for that of course we'd need your permission as the copyright licenses are different.

The unlit code in cpphs was largely taken from an early version of the Haskell Report.

Does that mean you do give us permission, or that you think we don't need your permission? I just want it to be clear, because cpphs is mostly LGPL and Cabal is BSD3.

...

...
Is there anyway to identify the cpphs version from running it? I don't see any --version flag or similar.

cpphs --version exists, and is documented.

Oh yes, you're quite right. Sorry I must have mis-typed (and cpphs --help doesn't mention it - not that it should necessarily). To be honest I think it'd be easier at the moment to update the unlit code rather than using cpphs --unlit because detecting that we actually need cpphs isn't done 'til rather late, so I'm not sure if we stick a version check in up front that we wouldn't end up unnecessarily failing in the configure step. Isaac knows this bit of the code much better than I do. Duncan

Malcolm Wallace

10 Oct 10 Oct

4:54 a.m.

Duncan Coutts writes:

...

...
...
One possibility would be to update to the latest cpphs unlit code, but for that of course we'd need your permission as the copyright licenses are different.

The unlit code in cpphs was largely taken from an early version of the Haskell Report.

Does that mean you do give us permission, or that you think we don't need your permission? I just want it to be clear, because cpphs is mostly LGPL and Cabal is BSD3.

I meant that the code is not mine, so you do not need my permission. An acknowledgement that the code was in the Haskell 1.2 Language Report is probably sufficient.

...

To be honest I think it'd be easier at the moment to update the unlit code rather than using cpphs --unlit

Yes, probably a better strategy. Use a library rather than an external tool (unless there are licensing issues to prevent it, which in this case there are not). Regards, Malcolm

6797

Age (days ago)

6800

Last active (days ago)

List overview

Download

5 comments

2 participants

participants (2)

Duncan Coutts
Malcolm Wallace