`callCabal2nixWithOptions name src opts args`
: Create a package named `name` from the source derivation `src` using
  `cabal2nix`.

  `opts` are extra options for calling `cabal2nix`. If `opts` is a string, it
  will be used as extra command line arguments for `cabal2nix`, e.g. `--subpath
  path/to/dir/containing/cabal-file`. Otherwise, `opts` should be an AttrSet
  which can contain the following attributes:

  `extraCabal2nixOptions`
  : Extra command line arguments for `cabal2nix`.

  `srcModifier`
  : A function which is used to modify the given `src` instead of the default
    filter.

    The default source filter will remove all files from `src` except for
    `.cabal` files and `package.yaml` files.

<!--

`callHackage`
: TODO

`callHackageDirect`
: TODO

`developPackage`
: TODO

-->

<!--

TODO(@NixOS/haskell): finish these planned sections
### Overriding the entire package set

## Contributing {#haskell-contributing}

### Fixing a broken package {#haskell-fixing-a-broken-package}

### Package set generation {#haskell-package-set-generation}

### Packaging a Haskell project

### Backporting {#haskell-backporting}

Backporting changes to a stable NixOS version in general is covered
in nixpkgs' `CONTRIBUTING.md` in general. In particular refer to the
[backporting policy](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#criteria-for-backporting-changes)
to check if the change you have in mind may be backported.

This section focuses on how to backport a package update (e.g. a
bug fix or security release). Fixing a broken package works like
it does for the unstable branches.

-->

## F.A.Q. {#haskell-faq}

### Why is topic X not covered in this section? Why is section Y missing? {#haskell-why-not-covered}

We have been working on [moving the nixpkgs Haskell documentation back into the
nixpkgs manual](https://github.com/NixOS/nixpkgs/issues/121403). Since this
process has not been completed yet, you may find some topics missing here
covered in the old [haskell4nix docs](https://haskell4nix.readthedocs.io/).

If you feel any important topic is not documented at all, feel free to comment
on the issue linked above.

### How to enable or disable profiling builds globally? {#haskell-faq-override-profiling}

By default, Nixpkgs builds a profiling version of each Haskell library. The
exception to this rule are some platforms where it is disabled due to concerns
over output size. You may want to…

* …enable profiling globally so that you can build a project you are working on
  with profiling ability giving you insight in the time spent across your code
  and code you depend on using [GHC's profiling feature][profiling].

* …disable profiling (globally) to reduce the time spent building the profiling
  versions of libraries which a significant amount of build time is spent on
  (although they are not as expensive as the “normal” build of a Haskell library).

::: {.note}
The method described below affects the build of all libraries in the
respective Haskell package set as well as GHC. If your choices differ from
Nixpkgs' default for your (host) platform, you will lose the ability to
substitute from the official binary cache.

If you are concerned about build times and thus want to disable profiling, it
probably makes sense to use `haskell.lib.compose.disableLibraryProfiling` (see
[](#haskell-trivial-helpers)) on the packages you are building locally while
continuing to substitute their dependencies and GHC.
:::

Since we need to change the profiling settings for the desired Haskell package
set _and_ GHC (as the core libraries like `base`, `filepath` etc. are bundled
with GHC), it is recommended to use overlays for Nixpkgs to change them.
Since the interrelated parts, i.e. the package set and GHC, are connected