Documentation

Perform the "./setup configure" action. Returns the .setup-config file.

After running configure, output the LocalBuildInfo to the localBuildInfoFile.

Read the localBuildInfoFile. Throw an exception if the file is missing, if the file cannot be read, or if the file was created by an older version of Cabal.

Read the localBuildInfoFile. Throw an exception if the file is missing, if the file cannot be read, or if the file was created by an older version of Cabal.

Check that localBuildInfoFile is up-to-date with respect to the .cabal file.

Try to read the localBuildInfoFile.

Try to read the localBuildInfoFile.

Return the "dist/" prefix, or the default prefix. The prefix is taken from (in order of highest to lowest preference) the override prefix, the "CABAL_BUILDDIR" environment variable, or the default prefix.

Return the "dist/" prefix, or the default prefix. The prefix is taken from (in order of highest to lowest preference) the override prefix, the "CABAL_BUILDDIR" environment variable, or defaultDistPref is used. Call this function to resolve a *DistPref flag whenever it is not known to be set. (The *DistPref flags are always set to a definite value before invoking UserHooks.)

This method computes a default, good enough ComponentId for a package. The intent is that cabal-install (or the user) will specify a more detailed IPID via the --ipid flag if necessary.

In GHC 8.0, the string we pass to GHC to use for symbol names for a package can be an arbitrary, IPID-compatible string. However, prior to GHC 8.0 there are some restrictions on what format this string can be (due to how ghc-pkg parsed the key):

1. In GHC 7.10, the string had either be of the form foo_ABCD, where foo is a non-semantic alphanumeric/hyphenated prefix and ABCD is two base-64 encoded 64-bit integers, or a GHC 7.8 style identifier.
2. In GHC 7.8, the string had to be a valid package identifier like foo-0.1.

So, the problem is that Cabal, in general, has a general IPID, but needs to figure out a package key / package ID that the old ghc-pkg will actually accept. But there's an EVERY WORSE problem: if ghc-pkg decides to parse an identifier foo-0.1-xxx as if it were a package identifier, which means it will SILENTLY DROP the xxx (because it's a tag, and Cabal does not allow tags.) So we must CONNIVE to ensure that we don't pick something that looks like this.

So this function attempts to define a mapping into the old formats.

The mapping for GHC 7.8 and before:

• For CLibName, we unconditionally use the PackageIdentifier.
• For sub-components, we create a new PackageIdentifier which is encoded in the following way. The test suite qux in package foobar-0.2 gets this package identifier z-foobar-z-test-qux-0.2. These package IDs have the form:

cpid ::= z- package-id -z- component-type - component-name component-type ::= test | bench | exe | lib package-id and component-name have - ( z + ) - segments encoded by adding an extra z.

The mapping for GHC 7.10:

• For CLibName: If the IPID is of the form foo-0.1-ABCDEF where foo_ABCDEF would validly parse as a package key, we pass ABCDEF. (NB: not all hashes parse this way, because GHC 7.10 mandated that these hashes be two base-62 encoded 64 bit integers), but hashes that Cabal generated using computeComponentId are guaranteed to have this form.

If it is not of this form, we rehash the IPID into the correct form and pass that.

• For sub-components, we rehash the IPID into the correct format and pass that.

Get the path of dist/setup-config.

List all installed packages in the given package databases.

A set of files (or directories) that can be monitored to detect when there might have been a change in the installed packages.

Like getInstalledPackages, but for a single package DB.

NB: Why isn't this always a fall through to getInstalledPackages? That is because getInstalledPackages performs some sanity checks on the package database stack in question. However, when sandboxes are involved these sanity checks are not desirable.

Compute the effective value of the profiling flags --enable-library-profiling and --enable-executable-profiling from the specified ConfigFlags. This may be useful for external Cabal tools which need to interact with Setup in a backwards-compatible way: the most predictable mechanism for enabling profiling across many legacy versions is to NOT use --enable-profiling and use those two flags instead.

Note that --enable-executable-profiling also affects profiling of benchmarks and (non-detailed) test suites.

Makes a BuildInfo from C compiler and linker flags.

This can be used with the output from configuration programs like pkg-config and similar package-specific programs like mysql-config, freealut-config etc. For example:

 ccflags <- rawSystemProgramStdoutConf verbosity prog conf ["--cflags"]
 ldflags <- rawSystemProgramStdoutConf verbosity prog conf ["--libs"]
 return (ccldOptionsBuildInfo (words ccflags) (words ldflags))

The user interface specifies the package dbs to use with a combination of --global, --user and --package-db=global|user|clear|$file. This function combines the global/user flag and interprets the package-db flag into a single package db stack.

The errors that can be thrown when reading the setup-config file.

Read the localBuildInfoFile, returning either an error or the local build info.

Relax the dependencies of this package if needed.