Re: Network.URI - MIN_VERSION_base problem, or finger-trouble?
Graham Klyne <GK <at> ninebynine.org>
2013-01-05 09:01:22 GMT
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.
(*) the final sequence I used was:
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:
>> 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.