On 6 November 2010 17:52, Reiner Pope wrote:

Ah, I hadn't thought of that. But doesn't the version of GHC change much more often than the version of base does?

Each major version of GHC has a different (major) version of base. I think you can also say stuff like "ghc >= 6.10", but I'm not sure. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

I was aware of this condition, but I'm not precisely sure it addresses my requirements. When you run "cabal install some-package", cabal reads all version constraints listed in the "build-depends" field, and chooses which versions of which packages to download from Hackage in order to satisfy these constraints. I want to expose my dependency on a particular version of ghc to cabal's constraint satisfier. The end result I want is that when you type "cabal install hmatrix-static" with ghc-6.12 installed, then cabal chooses hmatrix-static-0.3; and when you type "cabal install hmatrix-static" with ghc-7.0 installed, then cabal chooses hmatrix-static-0.4. As I understand it, using "impl(ghc >= 7.0)" won't achieve this. The closest thing I can think of is to write my hmatrix-static.cabal file for version 0.4 as:

... if impl(ghc < 7.0) build-depends: nonexistant-package ...

so that cabal cannot satisfy the constraints for hmatrix-static-0.4 unless I have ghc >= 7.0. This seems a little hacky, and I'm also not sure if it works. (I'm finding it rather hard to test these ideas, because I don't want to upload a new package to Hackage every time...) All the best, Reiner On 6 November 2010 19:24, wren ng thornton wrote:

On 11/6/10 3:13 AM, Ivan Lazar Miljenovic wrote:

...

On 6 November 2010 17:52, Reiner Pope  wrote:

...

Ah, I hadn't thought of that. But doesn't the version of GHC change much more often than the version of base does?

Each major version of GHC has a different (major) version of base.

I think you can also say stuff like "ghc>= 6.10", but I'm not sure.

The correct condition notation is: impl(ghc >= 6.10)

-- Live well, ~wren _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

wren ng thornton schrieb:

On 11/6/10 6:20 AM, Reiner Pope wrote:

...

I was aware of this condition, but I'm not precisely sure it addresses my requirements. When you run "cabal install some-package", cabal reads all version constraints listed in the "build-depends" field, and chooses which versions of which packages to download from Hackage in order to satisfy these constraints.

I want to expose my dependency on a particular version of ghc to cabal's constraint satisfier. The end result I want is that when you type "cabal install hmatrix-static" with ghc-6.12 installed, then cabal chooses hmatrix-static-0.3; and when you type "cabal install hmatrix-static" with ghc-7.0 installed, then cabal chooses hmatrix-static-0.4.

Clients of hmatrix-static would have to say

if impl(ghc >= 7.0) Build-Depends: hmatrix-static == 0.4.* else Build-Depends: hmatrix-static == 0.3.*

in order to pull in the right dependency for themselves.

Awful - I would not like to complicate my Cabal files this way. This is like copying the Build-Depends enumeration to all depending packages.

In order to get the behavior you're after, though, is trickier business. Since every version of GHC ships with a different version of base, you'll have to make use of that knowledge such that users of ghc-7.0 with base-5 will get hmatrix-static-0.4 whereas users of ghc-6.12 with base-4 will get hmatrix-static-0.3

I would not like this solution, too, since this assumes, that 'base' is a GHC-specific library and I hope this will be no longer true in the future. Does the LanguageExtensions field prevent building a package, if the installed compiler cannot handle that? I'm afraid, LanguageExtensions is just a list of flags that is passed to GHC. But it sounds like a good idea, if Cabal would also check, whether the used compiler supports the required LanguageExtensions at all.

On Sun, Nov 7, 2010 at 3:58 PM, wren ng thornton wrote:

On 11/7/10 11:54 AM, Henning Thielemann wrote:

...

Awful - I would not like to complicate my Cabal files this way. This is like copying the Build-Depends enumeration to all depending packages.

Oh, I agree :)

I wonder if you can include ghc in the build-tools: field and whether cabal-install bases its decisions on that field...

You can include ghc in that list, but I haven't been able to test to see if it changes the way cabal decides on installable packages. I doubt it. Tangentially -- you can add any program you wish to that field, but a little setup.hs hacking is necessary to get the version requirements check to work properly. Here's an example that checks for bnfc: main = do defaultMainWithHooks simpleUserHooks { hookedPrograms = [bnfcProgram] } bnfcProgram :: Program bnfcProgram = (simpleProgram "bnfc") { -- this assumes that --numeric-version prints *only* the dot-separated version id (eg: 6.12.0) programFindVersion = findProgramVersion "--numeric-version" id } With that in Setup.hs, you can specify version requirements in your cabal file as you normally would: eg: Build-tools: bnfc >= 2.4.2.0 && <= 2.5 Unfortunately, I don't know of any good way to share that Setup.hs code across multiple projects. --Rogan

Another option might be to have users set the preference: field in ~/.cabal/config. Though that requires user action again...

Why is the package ghc version specific anyways? Is it just a language extension thing?

...

Does the LanguageExtensions field prevent building a package, if the installed compiler cannot handle that? I'm afraid, LanguageExtensions is just a list of flags that is passed to GHC. But it sounds like a good idea, if Cabal would also check, whether the used compiler supports the required LanguageExtensions at all.

If you just wanted to ensure that things don't build on the wrong version, then you could always use a custom Setup.hs and use CPP to choose between exitSuccess and exitFailure somewhere along the way.

-- Live well, ~wren _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe