Graham Klyne | 29 Dec 19:25 2012

Network.URI - MIN_VERSION_base problem, or finger-trouble?

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:
[[
conina:tests graham$ ghc -v -XDeriveDataTypeable ../Network/URI.hs uri001.hs
Glasgow Haskell Compiler, Version 7.4.2, stage 2 booted by GHC version 7.0.4
Using binary package database: 
/Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/package.conf.d/package.cache
Using binary package database: 
/Users/graham/.ghc/x86_64-darwin-7.4.2/package.conf.d/package.cache
wired-in package ghc-prim mapped to 
ghc-prim-0.2.0.0-7d3c2c69a5e8257a04b2c679c40e2fa7
wired-in package integer-gmp mapped to 
integer-gmp-0.4.0.0-af3a28fdc4138858e0c7c5ecc2a64f43
wired-in package base mapped to base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to 
template-haskell-2.7.0.0-29110cc89a711d6ab3e7ee0e0a8ee949
wired-in package dph-seq not found.
(Continue reading)

Daniel Fischer | 30 Dec 01:18 2012

Re: Network.URI - MIN_VERSION_base problem, or finger-trouble?

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)
> ]]
(Continue reading)

Herbert Valerio Riedel | 1 Jan 15:19 2013
Picon

Re: Network.URI - MIN_VERSION_base problem, or finger-trouble?

Daniel Fischer <daniel.is.fischer <at> googlemail.com> 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

?
Edward Kmett | 1 Jan 17:18 2013
Picon

Re: Network.URI - MIN_VERSION_base problem, or finger-trouble?

On Tue, Jan 1, 2013 at 9:19 AM, Herbert Valerio Riedel <hvr <at> gnu.org> wrote:

Daniel Fischer <daniel.is.fischer <at> googlemail.com> 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


We do a mixture of these things in lens.

We set up 

#ifndef MIN_VERSION_foo
#define MIN_VERSION_foo(x,y,z) 1
#endif

guards for each MIN_VERSION_foo macro used within a model for development in case the user hasn't configured, and we set them to sensible defaults, (aka whatever works for me), and we have a .ghci file in the repository, that works once it has been configured and which helps support doctests and ghci users with:

:set -isrc -idist/build/autogen -optP-include -optPdist/build/autogen/cabal_macros.h
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Graham Klyne | 5 Jan 10:01 2013

Re: Network.URI - MIN_VERSION_base problem, or finger-trouble?

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

Gmane