Prepare to build a package by configuring a SetupMethod. The returned
Setup object identifies the method. The SetupScriptOptions may be changed
during the configuration process; the final values are given by
setupScriptOptions.
Modulecabal-install-3.12.1.0Haskell2010
Distribution.Client.SetupWrapper
An interface to building and installing Cabal packages.
If the Built-Type field is specified as something other than
Custom, and the current version of Cabal is acceptable, this performs
setup actions directly. Otherwise it builds the setup script and
runs it with the given arguments.
- 1 type
- 5 values
- Packagecabal-install-3.12.1.0
- Exports6
- LanguageHaskell2010
- LicenceBSD-3-Clause
- SourceSetupWrapper.hs
Run a configured Setup with specific arguments.
runSetupCommand Run a command through a configured Setup.
setupWrapper :: Verbosity-> SetupScriptOptions-> Maybe PackageDescription-> CommandUI flags-> (Version -> flags)produce command flags given the Cabal library version
-> (Version -> [String])-> IO ()
Configure a Setup and run a command in one step. The command flags
may depend on the Cabal library version in use.
SetupScriptOptions are options used to configure and run Setup, as
opposed to options given to the Cabal command at runtime.
Constructors
SetupScriptOptionsuseCabalVersion :: VersionRangeThe version of the Cabal library to use (if useDependenciesExclusive is not set). A suitable version of the Cabal library must be installed (or for some build-types be the one cabal-install was built with).
The version found also determines the version of the Cabal specification that we us for talking to the Setup.hs, unless overridden by useCabalSpecVersion.
useCabalSpecVersion :: Maybe VersionThis is the version of the Cabal specification that we believe that this package uses. This affects the semantics and in particular the Setup command line interface.
This is similar to useCabalVersion but instead of probing the system for a version of the Cabal library you just say exactly which version of the spec we will use. Using this also avoid adding the Cabal library as an additional dependency, so add it to useDependencies if needed.
useCompiler :: Maybe CompilerusePlatform :: Maybe PlatformusePackageDB :: PackageDBStackusePackageIndex :: Maybe InstalledPackageIndexuseProgramDb :: ProgramDbuseDistPref :: FilePathuseLoggingHandle :: Maybe HandleuseWorkingDir :: Maybe FilePathuseExtraPathEnv :: [FilePath]Extra things to add to PATH when invoking the setup script.
useExtraEnvOverrides :: [(String, Maybe FilePath)]forceExternalSetupMethod :: BooluseDependencies :: [(ComponentId, PackageId)]List of dependencies to use when building Setup.hs.
useDependenciesExclusive :: BoolIs the list of setup dependencies exclusive?
When this is
False, if we compile the Setup.hs script we do so with the list in useDependencies but all other packages in the environment are also visible. A suitable version ofCaballibrary (see useCabalVersion) is also added to the list of dependencies, unless useDependencies already contains a Cabal dependency.When
True, only the useDependencies packages are used, with other packages in the environment hidden.This feature is here to support the setup stanza in .cabal files that specifies explicit (and exclusive) dependencies, as well as the old style with no dependencies.
useVersionMacros :: BoolShould we build the Setup.hs with CPP version macros available? We turn this on when we have a setup stanza in .cabal that declares explicit setup dependencies.
useWin32CleanHack :: BoolsetupCacheLock :: Maybe LockisInteractive :: BoolIs the task we are going to run an interactive foreground task, or an non-interactive background task? Based on this flag we decide whether or not to delegate ctrl+c to the spawned task