Cabal/Developer-FAQ

How do I handle Haskell language extensions?

If your code uses some of the advanced Haskell extensions, you have a number of options.

Each language extension has a standard name. You can find the list in Language.Haskell.Extension.

1. The simplest way, if you're distributing via Cabal, is to add extensions: and the list of extensions names to your .cabal file. For example extensions: CPP, ForeignFunctionInterface. This allows every module in the package to use the listed extensions. Cabal will pass the appropriate flags to the compiler and it even checks that the compiler supports those extensions.
2. The best way to do it, if you know your users are using GHC 6.8.x is the new LANGUAGE pragma. This allows you to enable just those extensions that you are using in a particular module. For example stick

   {-# LANGUAGE CPP, ForeignFunctionInterface #-}
   

   at the top of the file.
3. An equivalent of the LANGUAGE pragma for older versions of GHC is the OPTIONS_GHC pragma (or for GHC 6.4 and older the OPTIONS pragma). The downside is that you have to know the GHC command line flag for the extensions you want. For example stick

   {-# OPTIONS_GHC -fffi -cpp #-}
   

   at the top of the file. Many other language extensions are enabled by -fglasgow-exts.

Conditional compilation

Executables with additional dependencies

Example Question: I want to build an executable for automated tests that depend on QuickCheck. However, building of tests is not necessary for installing the library and thus the dependency on QuickCheck is not always necessary. How can I explain that to Cabal?

Answer: Write something like the following into your Cabal file:

Flag buildTests

 description: Build test suite
 default:     False

Library

 ...

Executable test

 If flag(buildTests)
   Build-Depends: QuickCheck
 Else
   Buildable: False
 GHC-Options:    -Wall
 Hs-Source-Dirs: src
 Main-Is:        Test.hs

Enabling additional features via Cabal flags

Question: I like to let the user enable extended functionality using a Cabal flag. Is this the right way?

Answer: Certainly not. Since other packages can distinguish packages only according to their name and their version, it is not a good idea to allow different APIs for the same package version. Cumbersome as it is you have to move extra features to a separate package.

Adapt to different systems without CPP

Question: The Cabal documentation suggests to use the C preprocessor on Haskell code in order to adapt to system specific behaviour. I find this ugly. Is there another way?

Answer: You can put modules with the same name and API in different directories and choose the right module using a Cabal test.

-- necessary packaging all module variants when doing 'sdist' Extra-Source-Files:

 src-i386/CPU/Dependent/Module.hs
 src-gen/CPU/Dependent/Module.hs

Exposed-Modules:

 CPU.Dependent.Module
 ...

If arch(i386)

 Hs-Source-Dirs: src-i386

Else

 Hs-Source-Dirs: src-gen

On the one hand it is a bit cumbersome to maintain the separate directory trees, on the other hand the modules can be read as they are and the reader does not need to untangle nested #if directives. Separation of OS dependent code into individual modules is certainly a good idea anyway, however if you want to adapt to many combinations of compilers and their versions, operating systems and processors then the above approach will make things worse.