Cabal packages

haskell_cabal_binary

haskell_cabal_binary(name, deps, srcs, cabalopts, compiler_flags, exe_name, flags,
                     generate_paths_module, setup_deps, tools, verbose)

Use Cabal to build a binary.

Examples

haskell_cabal_binary(
    name = "happy",
    srcs = glob(["**"]),
)

This rule assumes that the .cabal file defines a single executable with the same name as the package.

This rule does not use cabal-install. It calls the package’s Setup.hs script directly if one exists, or the default one if not. All sources files that would have been part of a Cabal sdist need to be listed in srcs (crucially, including the .cabal file).

Attributes

haskell_cabal_library

haskell_cabal_library(name, deps, srcs, cabalopts, compiler_flags, flags, generate_paths_module,
                      haddock, package_name, setup_deps, sublibrary_name, tools, unique_name, verbose,
                      version)

Use Cabal to build a library.

Examples

haskell_cabal_library(
    name = "lib-0.1.0.0",
    srcs = ["lib.cabal", "Lib.hs", "Setup.hs"],
)

haskell_toolchain_library(name = "base")

haskell_binary(
    name = "bin",
    deps = [":base", ":lib-0.1.0.0"],
    srcs = ["Main.hs"],
)

This rule does not use cabal-install. It calls the package’s Setup.hs script directly if one exists, or the default one if not. All sources files that would have been part of a Cabal sdist need to be listed in srcs (crucially, including the .cabal file). A haskell_cabal_library can be substituted for any haskell_library. The two are interchangeable in most contexts. However, using a plain haskell_library sometimes leads to better build times, and does not require drafting a .cabal file.

Attributes

stack_snapshot

stack_snapshot(name, stack, extra_deps, vendored_packages, snapshot, local_snapshot,
               stack_snapshot_json, packages, flags, haddock, setup_deps, tools, components,
               components_dependencies, stack_update, verbose, netrc, toolchain_libraries,
               setup_stack, label_builder, kwargs)

Use Stack to download and extract Cabal source distributions.

This rule will use Stack to compute the transitive closure of the subset of the given snapshot listed in the packages attribute, and generate a dependency graph. If a package in the closure depends on system libraries or other external libraries, use the extra_deps attribute to list them. This attribute works like the --extra-{include,lib}-dirs flags for Stack and cabal-install do. If a package has a custom setup with setup dependencies, use the setup_deps attribute to list them.

Packages that are in the snapshot need not have their versions specified. But any additional packages or version overrides will have to be specified with a package identifier of the form <package>-<version> in the packages attribute. Note that you cannot override the version of any packages built into GHC.

This rule invokes the stack tool for version and dependency resolution based on the specified snapshot. You can generate a stack_snapshot.json file to avoid invoking stack on every fetch and instead pin the outcome in a file that can be checked into revision control. Execute the following command:

bazel run @stackage-unpinned//:pin

Then specify the stack_snapshot_json attribute to point to the generated file:

stack_snapshot(
    ...
    stack_snapshot_json = "//:stackage_snapshot.json",
)

By default stack_snapshot defines a library target for each package. If a package does not contain a library component or contains executable components, then you need to declare so yourself using the components attribute. Library targets are exposed as @stackage//:<package-name> and executables are exposed as @stackage-exe//<package-name>:<executable-name>, assuming that you invoked stack_snapshot with name = "stackage".

In the external repository defined by the rule, all items of the packages attribute and all items of the vendored_packages attribute are made available as top-level targets named after each package with public visibility. Other packages that are dependencies of vendored packages are made available with visibility restricted to these vendored packages.

The dependency graph is made available within packages.bzl as the dict packages mapping unversioned package names to structs holding the fields

• name: The unversioned package name.
• version: The package version.
• library: Whether the package has a declared library component.
• executables: List of declared executable components.
• deps: The list of library dependencies according to stack.
• tools: The list of tool dependencies according to stack.
• flags: The list of Cabal flags.
• visibility: The visibility of the given package.

NOTE: Make sure your GHC version matches the version expected by the snapshot. E.g. if you pass snapshot = "lts-20.3", make sure you use GHC 9.2.5 (e.g. by invoking rules_haskell_toolchains(version="9.2.5")). Sadly, rules_haskell cannot maintain this correspondence for you. You will need to manage it yourself. If you have a version mismatch, you will end up with versions of core GHC packages which do not match the versions listed in the snapshot, and potentially other problems.

Examples

stack_snapshot(
    name = "stackage",
    packages = ["conduit", "doctest", "lens", "zlib-0.6.2"],
    vendored_packages = {"split": "//split:split"},
    tools = ["@happy//:happy"],  # Use externally provided `happy`
    components = {
        "doctest": ["lib", "exe"],  # Optional since doctest is known to have an exe component.
        "happy": [],  # Override happy's default exe component.
    },
    snapshot = "lts-20.3",
    extra_deps = {"zlib": ["@zlib.dev//:zlib"]},
)

defines @stackage//:conduit, @stackage//:doctest, @stackage//:lens, @stackage//:zlib library targets and a @stackage-exe//doctest executable target. It also uses an externally provided happy rather than the one provided by the snapshot.

Alternatively

stack_snapshot(
    name = "stackage",
    packages = ["conduit", "doctest", "lens", "zlib"],
    flags = {"zlib": ["-non-blocking-ffi"]},
    tools = ["@happy//:happy"],  # Use externally provided `happy`
    components = {
        "doctest": ["lib", "exe"],  # Optional since doctest is known to have an exe component.
        "happy": [],  # Override happy's default exe component.
    },
    local_snapshot = "//:snapshot.yaml",
    extra_deps = {"zlib": ["@zlib.dev//:zlib"]},

Does the same as the previous example, provided there is a snapshot.yaml, at the root of the repository with content

resolver: lts-20.3

packages:
  - zlib-0.6.2

Attributes

{
    "postgresql-libpq": ["@postgresql//:include"],
    "zlib": ["@zlib.dev//:zlib"]
}

components_dependencies = {
  "package-name": """{"lib:package-name": ["lib:sublib1", "lib:sublib2"]}""",
},

rules_haskell_asterius_toolchains(version = "0.0.1")
load("@linux_amd64_asterius//:toolchain_libraries.bzl", "toolchain_libraries")
stack_snapshot(
    ...,
    toolchain_libraries = toolchain_libraries,
    ...,
)

use_stack

use_stack(stack)

Force given stack binary in all invocations of stack_snapshot.

Globally override the stack version used by all instances of stack_snapshot. WARNING: This should only be used in the top-level repository.

Examples

# WORKSPACE

# Order is important! Placing `use_stack()` after any occurrence of `stack_snapshot`
# (also any one nested within another macro call) will fail the build.
use_stack("@x_stack//:stack")
stack_snapshot(
    name = "x",
    # this is ignored due to `use_stack()
    stack = "@y_stack:stack",
    # ...
)

# BUILD.bazel
haskell_binary(
    # ...
    # targets in `x` will be built using `x_stack`, NOT `y_stack`
    deps = ["@x//:all"],
)

Attributes