Daniel Fischer writes: [...]

When hacking on a package without using cabal, you can

a) remove the problematic macro b) define it in the file yourself c) pass -D"MIN_VERSION_base(x,y,z)=1" on the command line

what about mimicking what cabal does, e.g. create a CPP file (e.g. 'cabal_macros.h') with the needed definitions and call ghc(i) something along the lines of ghci -optP-include -optPcabal_macros.h TheModule.hs ?

Thanks Daniel, and others, for the hints. In the end I used your command line option, and all was fine. After submitting my pull request, I finally managed to get the test suite running using cabal, following a bit of trial-end-error (*), which has raised a couple of questions for me: 1. Is there a simple "one page" introduction to using cabal with an existing library/package - i.e. for building/testing a simple change? 2. Is there a simple way to get detailed test results displayed to the console when running tests through cabal? I tried -v but that didn't help. I ask as a very occasional Haskell user who is not steeped in, or even regularly exposed to, the traditions and practices of the GHC/Cabal toolchain. #g -- (*) the final sequence I used was: 541 autoreconf 555 cabal configure --enable-tests 557 cabal build 561 cabal test --log=a.tmp 563 cat dist/test/a.tmp On 30/12/2012 00:18, Daniel Fischer wrote:

On Samstag, 29. Dezember 2012, 18:25:45, Graham Klyne wrote:

...

A couple of problems with Network.URI have been brought to my attention, so I thought I'd have a go at seeing if I could fix them. It's been a while (years) since I used the Haskell toolchain in anger, so I'm a bit out of touch with how thinks are working now.

So far, I have:

1. Installed Haskell platform (64-bit version for MacOS). 2. Checked out the 'network' project from https://github.com/haskell/network 3. cabal install test-framework 4. cabal install test-framework-hunit 5. changed to the 'test' directory of the checked out 'network' project

Then when I try to run GHC, I get this error: <snip>

The problem seems to be with the following lines in URI.hs (starting at line 135): [[ # if MIN_VERSION_base(4,0,0) import Data.Data (Data) # else import Data.Generics (Data) # endif ]]

If I remove these lines, and just leave [[ import Data.Generics (Data) ]]

I can compile and run the test suite just fine: [[ Test Cases Total Passed 319 319 Failed 0 0 Total 319 319 ]]

I'm _guessing_ the problem here is something to do with "MIN_VERSION_base(4,0,0)" - not being familiar with the current build environment setup, I'm not sure where it is or should be defined, or what it is intended to mean.

The MIN_VERSION_package is a macro that cabal creates when building the package, that checks whether the available package version satisfies the minimum requirements.

When hacking on a package without using cabal, you can

a) remove the problematic macro b) define it in the file yourself c) pass -D"MIN_VERSION_base(x,y,z)=1" on the command line

(I've tested option c only for C code, it might not work here, but afaik, gcc's preprocessor is used, so I think it will).

Since you will probably compile more than once, a) or b) would be the preferable options.

But you could also leave the macro as is and just

$ cabal build

the package. That needs one

$ cabal configure

before the first build, after that, a `cabal build` will only recompile changed modules (and what depends on them), so the compilation should be reasonably fast.

...

I did find these: * http://www.haskell.org/pipermail/haskell-cafe/2012-August/102787.html * http://stackoverflow.com/questions/8961413/zlib-build-error-with-ghc but they didn't help me.

It seems there's a fix that involves using __GLASGOW_HASKELL__ instead of MIN_VERSION_base(4,0,0), but I'm not sure exactly how that would play out - or indeed if that's the correct approach for a permanent fix.

In principle, the MIN_VERSION macro is the right thing, because it tests for the package version where things changed. For base, a suitable __GLASGOW_HASKELL__ condition is of course equivalent to a base-version check.