[Haskell-cafe] Compiler constraints in cabal

Rogan Creswick creswick at gmail.com
Mon Nov 8 11:58:47 EST 2010

On Sun, Nov 7, 2010 at 3:58 PM, wren ng thornton <wren at freegeek.org> 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:

    bnfc >= && <= 2.5

Unfortunately, I don't know of any good way to share that Setup.hs
code across multiple projects.


> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list