What kind of VCS repository is this?

Version control systems.

Takes the last non-Nothing value, or returns Nothing if both values are Nothing.

A single repository section. This is an instance of Monoid, so to get a blank Repository section, use mempty.

Creates a Section that is a Repository for a Github head. For example, for Cartel, use githubHead "massysett" "cartel".

Creates a Section for a repository.

Condition; for use in a CondTree and ultimately in a CondBlock, which implements Cabal's if-then-else feature.

For use in a CondTree or ConstrTree.

Whether or equal to comparisions are also true.

Expresses comparisons between versions.

Expresses a tree of constraints. This is how you represent more complex dependency relationships.

Expresses any version constraint, including no version constraint.

Conditions. Ultimately these are used in a CondBlock.

Like not, which is what I would have named it but for the conflict. Only Conditions have this sort of operation; Cabal does not have a (documented, at least) way to express this for package constraints.

Conditional blocks. These implement the if-then-else feature of Cabal files. You must have at least one thing to do if the condition is True; the if-false block is optional.

Less than

Greater than

Equal to

Less than or equal to

Greater than or equal to

Matches any version at all (in a Cabal file, this is represented as an empty string).

Creates a package interval that is closed on the left, open on the right. Useful for the common case under the PVP to specify that you depend on a version that is at least a particular version, but less than another version.

closedOpen "bytestring" [0,17] [0,19] ==> bytestring >= 0.17 && < 0.19

Specifies a particular API version. Useful to lock your package dependencies down to a particular API version.

apiVersion "base" [1] ==> base >= 1 && < 2
apiVersion "base" [1,2] ==> base >= 1.2 && < 1.3
apiVersion "base" [1,2,3] ==> base >= 1.2.3 && < 1.2.4

Depends on the version given, up to the next breaking API change.

nextBreaking "base" [4] ==> base >= 4 && < 4.1
nextBreaking "base" [4,1] ==> base >= 4.1 && < 4.2
nextBreaking "base" [4,7,0,0] ==> base >= 4.7.0.0 && < 4.8

Depends on the version given, up to the next time the first digit increments. Useful for base.

nextBreaking "base" [4] ==> base >= 4 && < 5

Depends on exactly this version only.

exactly "base" [4,5,0,0] ==> base ==4.5.0.0

Depends on this version, or any greater version.

atLeast "base" [4,5,0,0] ==> version >= 4.5.0.0

Allows any version of a package.

Builds if statements. For example:

condition (flag "buildExe") (buildable True, []) [buildable False]

A little more complicated:

condition (flag "buildExe" &&& system "windows")
  (buildable True, []) [buildable False]

Operating system; tested against System.Info.os on the target system.

Argument is matched against System.Info.arch on the target system.

Tests for the configured Haskell implementation.

Evaluates to the current assignment of the flag of the given name. Flag names are case insensitive. Testing for flags that have not been introduced with a flag section is an error.

Always true.

Always false.

A version number. The Cabal documentation says this "usually" consists of a sequence of natural numbers separated by dots. Though this suggests that a version number could contain something other than natural numbers, in fact the types in the Cabal library do not allow anything other than numbers and you will get a parse error if you try to use anything else.

Therefore Cartel's Version type only allows a list of Word, as each number cannot be negative. In addition, this list should never be empty. However, this is just a type synonym for a list of Word, so the type system does not enforce the requirement that this list be non-empty.

A single package, consisting of a package name and an optional set of constraints. Used when specifying buildDepends, buildTools, and pkgConfigDepends.

Some functions exist to ease the creation of a Package. For a package with no version constrains, simply do something like unconstrained "QuickCheck". Common use cases are covered in the functions in the "Package Helpers" section below. For something more complicated, use the functions in the "Logicals" sections above, along with the &&& and ||| combinators, to create your own Constraint and then use it with the package function.

Builds a Package.

Default language. Currently not documented, see

https://github.com/haskell/cabal/issues/1894

Sets Haskell 98 as the default-language.

Currently not documented in Cabal, see

https://github.com/haskell/cabal/issues/1894

Sets Haskell 2010 as the default-language.

Currently not documented in Cabal, see

https://github.com/haskell/cabal/issues/1894

A single field of build information. This can appear in a Library, Executable, TestSuite, or Benchmark.

A field in the Library section of the Cabal file. A Library section can have multiple fields.

Whether a library is exposed. GHC can hide libraries.

A library's exposed modules. modules can help you generate this, without you having to manually list each module and keep the list up to date.

A single field in an Executable section. An Executable section may have multiple fields.

An entire Executable section.

Builds a Section for executable files.

What kind of test suite is this?

A single field value in a TestSuite section. A single test suite section may contain mulitple fields.

The module exporting the tests symbol. This is required when using Detailed and disallowed when using ExitcodeStdio.

An entire test-suite section.

Builds a Section for test suites.

A single field in a Benchmark section.

An entire Benchmark section.

Builds a Section for benchmarks.

Things that can be an item in a build information field in a Cabal file.

A list of packages needed to build this component

Modules used but not exposed. For libraries, these are hidden modules; for executable, these are auxiliary modules to be linked with the file in the main-is field.

modules can help greatly with maintenance of this field.

Root directories for the module hierarchy

Haskell extensions used by every module. With version 1.22 of the Cabal library, using this field might get you this warning:

Warning: For packages using 'cabal-version: >= 1.10' the
'extensions' field is deprecated. The new 'default-extensions'
field lists extensions that are used in all modules in the
component, while the 'other-extensions' field lists extensions
that are used in some modules, e.g. via the {-# LANGUAGE #-}
pragma.

Default extensions. See extensions for details. Currently undocumented, see https://github.com/haskell/cabal/issues/1517

Other extensions. See extensions for details. Currently undocumented, see https://github.com/haskell/cabal/issues/1517

Programs needed to build this package, such as c2hs.

Is this component buildable?

Header files to be included in any compilations via C. Applies to both header files that are already installed on the system and to those coming with the package to be installed.

Header files to be installed into $libdir/includes when the package is installed. These files should be found in relative to the top of the source tree or relative to one of the directories listed in include-dirs.

List of diretories to search for header files when dealing with C compilations.

C sources to be compiled and lined with the Haskell files.

Extra libraries to link with.

Directories to search for libraries.

C Compiler options.

C Preprocessor options. Undocumented, see https://github.com/haskell/cabal/issues/646

Linker options.

List of pkg-config packages needed to build this component.

OS X frameworks.

Sections that build executables. These are the Executable, Benchmark, and TestSuite sections.

Sections that build executables that can be exitcode-stdio-1.0. These are the Benchmark and TestSuite sections.

Builds two fields. The first indicates that this is an exitcode-stdio-1.0 executable; the second is the appropriate main-is field.

Gets all Haskell modules in a given directory tree. Allows you to specify what extensions you are interested in. For this to work best, you will want to keep all your library modules in their own directory, such as lib/. You can also separate executables and test suites this way. hsSourceDirs will then tell Cabal to use these directories.

Same as

modulesWithExtensions fileExtensions

Common extensions of Haskell files and files that are preprocessed into Haskell files. Includes:

• hs (Haskell)
• lhs (literate Haskell)
• gc (greencard)
• chs (c2hs)
• hsc (hsc2hs)
• y and ly (happy)
• x (alex)
• cpphs

Gets all Haskell modules in a given directory tree. Only files with one of the extensions listed in fileExtensions are returned. Files and directories that do not begin with an uppercase letter are ignored. (This also ignores files that start with a dot.) Directories with a dot anywhere in the name are ignored.

Gets all Haskell modules in a given directory tree. Allows you to specify what extensions you are interested in.

A single section in a Cabal file; this may be a source repository, executable, test suite, or benchmark. You build a Section with the repository, executable, testSuite, and benchmark functions.

Global package properties. Is an instance of Monoid so to get a blank Properties use mempty, for example:

properties = mempty
 { name = "mypackage"
 , version = [0,1]
 , cabalVersion = Just (1,10)
 , buildType = Just simple
 -- etc.  Fields you don't supply will be blank.
 }

Many of these fields hold a Maybe type. Values that are Nothing will generate no output in the resulting Cabal file. Other fields are a String type. Empty strings will generate no output in the resulting Cabal file. Other values are lists; empty lists generate no output in the resulting Cabal file.

Represents an entire Cabal file. Is an instance of Monoid so to get a blank Cabal use mempty.