Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Cabal project files

A cabal project normally consists of two configuration files:

  1. <project_name>.cabal - defines the project metadata.

  2. cabal.project - defines the build configuration options of the project.

<project_name>.cabal

Reference

Let's start with the project.cabal file. This file is named as <project_name>.cabal. We will use the plutus-scripts files as examples so this file is plutus-scripts.cabal. The first line of the file states the Cabal-Version of the project which is the specification version that this package description uses. The following lines contain some basic metadata about the project (author, licence, etc...):

# plutus-scripts/plutus-scripts.cabal

Cabal-Version:      2.4
Name:               plutus-script
Version:            0.1.0.0
Author:             James Browning
Maintainer:         james.browning@iohk.io
Build-Type:         Simple
Copyright:          © 2022 James Browning
License:            Apache-2.0
License-files:      LICENSE

After that, we get the definition of the project type. A project can be a library or an executable. It can also be both of those. The plutus-scripts project is a library with source code located in the src directory and exposes the listed modules:

The next section build-depends specifies the library dependencies required to build the project. Dependencies can have specific versions specified:

The following two options default-language and ghc-options specify the language specification to use (in this case Haskell2010), and the GHC options for the compiler to use when building the project:

cabal.project

Reference

The cabal.project file supports a variety of options that configure the details of your build. Perhaps most importantly, it specifies dependencies which are not on Hackage. In plutus-scripts, the first definition in the file is for the Cardano Haskell package repository which aims to be the central package repository for Cardano-related packages not found on Hackage.

This instructs cabal to look for packages in that repository as well. The packages field specifies the list of package locations that contain the local packages to be built by this project. The index-state field instructs cabal to look for packages in repositories (Hackage/CHaP etc.) with the state of those repositories as it was at the given time.

The constraints field defines specific version constraints and can also specify flag settings.

A source-repository-package field provides a location from where to build a certain dependency that is not found on central repositories such as Hackage or CHaP, as is the case here for plutus-apps packages.

PreviousSetting up your Plutus development environmentNextGeneral Notes

Last updated