stack 2.15.3 → 2.15.5
raw patch · 15 files changed
+418/−150 lines, 15 filesdep ~pantry
Dependency ranges changed: pantry
Files
- ChangeLog.md +16/−0
- cabal.config +1/−1
- doc/ChangeLog.md +16/−0
- doc/GUIDE.md +7/−7
- doc/build_command.md +197/−72
- doc/debugging.md +33/−9
- doc/exec_command.md +26/−0
- doc/new_command.md +5/−0
- doc/run_command.md +13/−4
- doc/stack_root.md +12/−3
- doc/upload_command.md +1/−1
- doc/yaml_configuration.md +9/−1
- src/Stack/Build/ExecuteEnv.hs +65/−46
- src/Stack/Config.hs +12/−1
- stack.cabal +5/−5
ChangeLog.md view
@@ -1,5 +1,21 @@ # Changelog +## v2.15.5 - 2024-03-28 + +Release notes: + +* This release fixes potential bugs. + +**Changes since v2.15.3:** + +Behaviour changes: + +* Following the handover of the Stackage project to the Haskell Foundation, the + default value of the `urls` key is + `latest-snapshot: https://stackage-haddock.haskell.org/snapshots.json`. +* Stack no longer includes the snapshot package database when compiling the + setup executable for a package with `build-type: Configure`. + ## v2.15.3 - 2024-03-07 Release notes:
cabal.config view
@@ -163,7 +163,7 @@ , socks ==0.6.1 , split ==0.2.5 , splitmix ==0.1.0.5 - , stack ==2.15.3 + , stack ==2.15.5 , static-bytes ==0.1.0 , stm ==2.5.1.0 , stm-chans ==3.0.0.9
doc/ChangeLog.md view
@@ -1,5 +1,21 @@ # Changelog +## v2.15.5 - 2024-03-28 + +Release notes: + +* This release fixes potential bugs. + +**Changes since v2.15.3:** + +Behaviour changes: + +* Following the handover of the Stackage project to the Haskell Foundation, the + default value of the `urls` key is + `latest-snapshot: https://stackage-haddock.haskell.org/snapshots.json`. +* Stack no longer includes the snapshot package database when compiling the + setup executable for a package with `build-type: Configure`. + ## v2.15.3 - 2024-03-07 Release notes:
doc/GUIDE.md view
@@ -286,7 +286,7 @@ In this guide, we'll discuss the bare minimum necessary to understand how to modify a `package.yaml` file. You can see a full list of the available options at the [Hpack documentation](https://github.com/sol/hpack#quick-reference). The -Cabal User Guide the definitive reference for the +Cabal User Guide is the definitive reference for the [Cabal file format](https://cabal.readthedocs.io/en/stable/cabal-package.html). ### The location of GHC @@ -505,7 +505,7 @@ a bit of information about it at [https://www.stackage.org/lts](https://www.stackage.org/lts), including: -* The appropriate value (`lts-22.7`, as is currently the latest LTS) +* The appropriate value (`lts-22.13`, as is currently the latest LTS) * The GHC version used * A full list of all packages available in this snapshot * The ability to perform a Hoogle search on the packages in this snapshot @@ -523,16 +523,16 @@ ## Snapshots and changing your compiler version -Let's explore package sets a bit further. Instead of `lts-22.7`, let's change +Let's explore package sets a bit further. Instead of `lts-22.13`, let's change our `stack.yaml` file to use the [latest nightly](https://www.stackage.org/nightly). Right now, this is currently -2023-09-24 - please see the snapshot from the link above to get the latest. +2024-03-20 - please see the snapshot from the link above to get the latest. Then, commanding `stack build` again will produce: ~~~text stack build -# Downloaded nightly-2023-09-24 build plan. +# Downloaded nightly-2024-03-20 build plan. # build output ... ~~~ @@ -540,8 +540,8 @@ Continuous Integration (CI) setting, like on Travis. For example, command: ~~~text -stack --snapshot lts-20.26 build -# Downloaded lts-20.26 build plan. +stack --snapshot lts-21.25 build +# Downloaded lts-21.25 build plan. # build output ... ~~~
doc/build_command.md view
@@ -72,95 +72,139 @@ ## Target syntax `stack build` takes a list of one or more optional *targets* to be built. The -supported syntaxes for targets are: +supported syntaxes for targets are as follows: -* *package*, e.g. `stack build foobar`, is the most commonly used target. It - will try to find the package in the following locations: project packages, - extra-deps, the snapshot, and the package index (e.g. Hackage). If it's - found in the package index, then the latest version of that package from the - index is implicitly added as an extra-dep. +* no targets specified +* *package* +* *package identifier* +* project package *component* +* *local directory* - If the package is a project package, the library and executable components - are selected to be built. If the `--test` and `--bench` flags are set, then - all of the test suite and benchmark components, respectively, are selected - to be built. +### No targets specified - If *package* is a GHC boot package (packages that come with GHC and are - included in GHC's global package database), the behaviour can be complex. - If the boot package has not been 'replaced', then `stack build` will, - effectively, do nothing. However, if the boot package has been 'replaced' - then `stack build` will specify the latest version of that package in the - package index, which may differ from the version provided by the version of - GHC specified by the snapshot. A boot package will be treated as 'replaced' - if the package is included directly in the Stackage snapshot or it depends - on a package included directly in the snapshot. Stackage snapshots do not - include directly most boot packages but some snapshots may include directly - some boot packages. In particular, some snapshots include directly `Win32` - (which is a boot package on Windows) while others do not. For example, if - `Cabal` (a boot package) is not a project package or an extra-dep, then - `stack build Cabal` with Stackage snapshot LTS Haskell 20.25 will: +Example: `stack build` - * on Windows, try to build the latest version of `Cabal` in the package - index (because that snapshot includes `Win32` directly, and `Cabal` - depends on `Win32` and so is treated as 'replaced'); and - * on non-Windows, effectively, do nothing (because `Cabal` is not - 'replaced'). +`stack build` with no targets specified will build all project packages. -* *package identifier*, e.g. `stack build foobar-1.2.3`, is usually used to - include specific package versions from the package index. +### Target: *package* - If the package name conflicts with that of a project package, then Stack - fails with an error. +Example: `stack build foobar` - Otherwise, this is the same as using `stack build foobar` (that is, ignoring - the specified version), unless the specified version exists in the package - index. If it exists, then the latest revision of that version from the - package index is used. +Stack will try to find the package in the following locations: -* *component*. Instead of referring to an entire package and letting Stack - decide which components to build, you select individual components from - inside a package. This can be done for more fine-grained control over which - test suites to run, or to have a faster compilation cycle. There are - multiple ways to refer to a specific component (provided for convenience): +* project packages, +* extra-deps, +* the snapshot, and +* the package index (e.g. Hackage). - * `<package-name>:lib` or `<package-name>:<comp-type>:<comp-name>` (where - the component type, `<comp-type>`, is one of `exe`, `test`, or `bench`) - is the most explicit. The library component type (`lib`) does not have - an associated component name, `<comp-name>`. +If the package is found in the package index, then the latest version of that +package from the index is implicitly added as an extra-dep. - !!! note +If the package is a project package, the library and executable components are +selected to be built. If the `--test` and `--bench` flags are set, then all of +the test suite and benchmark components, respectively, are selected to be built. - When any `exe` component is specified, all of the package's - executable components will be built. This is due to limitations in - all currently released versions of Cabal. See - [issue#1046](https://github.com/commercialhaskell/stack/issues/1406) +If *package* is a GHC boot package (packages that come with GHC and are included +in GHC's global package database), the behaviour can be complex: - * `<package-name>:<comp-name>` allows you to leave out the component type, - as that will often be unique for a given component name. For - example, `stack build mypackage:mytestsuite`. +* If the boot package has not been 'replaced', then `stack build` will, + effectively, do nothing. - * `:<comp-name>` is a useful shortcut, saying "find the component - `<comp-name>` in all of the project packages". This will result in an - error if more than one package has a component with the specified name. - To continue the above example, `stack build :mytestsuite`. +* If the boot package has been 'replaced' then `stack build` will specify the + latest version of that package in the package index, which may differ from the + version provided by the version of GHC specified by the snapshot. -* *directory*, e.g. `stack build foo/bar`, will find all project packages that - exist in the given directory hierarchy and then follow the same procedure as - passing in package names as mentioned above. There's an important caveat - here: if your directory name is parsed as one of the above target types, it - will be treated as that. Explicitly starting your target with `./` can be a - good way to avoid that, e.g. `stack build ./foo`. +A boot package will be treated as 'replaced' if the package is included directly +in the Stackage snapshot or it depends on a package included directly in the +snapshot. - !!! note +!!! note - `stack build .` will target project packages in the current working - directory or its subdirectories. + Stackage snapshots do not include directly most boot packages but some + snapshots may include directly some boot packages. In particular, some + snapshots include directly `Win32` (which is a boot package on Windows) + while others do not. -`stack build` with no targets specified will build all project packages. + For example, if `Cabal` (a boot package) is not a project package or an + extra-dep, then `stack build Cabal` with Stackage snapshot LTS Haskell 20.25 + will: + * on Windows, try to build the latest version of `Cabal` in the package + index (because that snapshot includes `Win32` directly, and `Cabal` + depends on `Win32` and so is treated as 'replaced'); and + * on non-Windows, effectively, do nothing (because `Cabal` is not + 'replaced'). + +### Target: *package identifier* + +Example: `stack build foobar-1.2.3` + +If the package name is that of a project package, then Stack fails with an +error. + +If the package version is in the package index (e.g. Hackage) then Stack will +use the latest revision of that version from the package index. + +If the package is an extra-dep or in the snapshot, Stack will behave as if only +the package name had been specified as the target (that is, ignoring the +specified version). + +Otherwise, Stack will fail with an error, reporting that the package name is +unknown. + +### Target: project package *component* + +Examples: + +* `stack build my-package:lib` +* `stack build my-package:exe:my-executable` +* `stack build my-package:test:my-test-suite` +* `stack build my-package:bench:my-benchmark` +* `stack build my-package:my-test-suite` +* `stack build :my-test-suite` + +You can select individual components from inside a project package to be built. +This can be done for more fine-grained control over which test suites to run, or +to have a faster compilation cycle. + +There are multiple ways to refer to a specific component: + +* `<package-name>:lib` or `<package-name>:<comp-type>:<comp-name>` (where the + component type, `<comp-type>`, is one of `exe`, `test`, or `bench`) is the + most explicit. The library component type (`lib`) does not have an + associated component name, `<comp-name>`. + +* `<package-name>:<comp-name>` allows you to leave out the component type, as + that will often be unique for a given component name. + +* `:<comp-name>` is a useful shortcut, saying "find the component`<comp-name>` + in all of the project packages". This will result in an error if more than + one package has a component with the specified name. + For further information about available targets, see the [`stack ide targets` command](ide_command.md). +### Target: *local directory* + +Examples: + +* `stack build foo/bar` +* `stack build ./foo` +* `stack build .` + +Stack will find all project packages that exist in the given directory hierarchy +and then follow the same procedure as passing in package names as mentioned +above. + +`stack build .` will target project packages in the current working directory or +its subdirectories. + +!!! note + + If the directory name is parsed as one of the other target types, it will + be treated as that. Explicitly starting the target with `./` can avoid that. + For example, `stack build ./foo`. + ## Controlling what gets built Stack will automatically build the necessary dependencies. See the introductory @@ -259,7 +303,7 @@ Unset the flag to disable building Haddock documentation for dependencies. -### `--[no-]haddock-for-haddock` flag +### `--[no-]haddock-for-hackage` flag :octicons-beaker-24: Experimental @@ -316,7 +360,7 @@ Unset the flag to disable building building hyperlinked source for Haddock. -If the [`--haddock-for-hackage`](#-no-haddock-for-haddock-flag) flag is passed, +If the [`--haddock-for-hackage`](#-no-haddock-for-hackage-flag) flag is passed, this flag is ignored. ### `--[no-]haddock-internal` flag @@ -325,7 +369,7 @@ Set the flag to enable building Haddock documentation for internal modules. -If the [`--haddock-for-hackage`](#-no-haddock-for-haddock-flag) flag is passed, +If the [`--haddock-for-hackage`](#-no-haddock-for-hackage-flag) flag is passed, this flag is ignored. ### `--[no-]keep-going` flag @@ -428,15 +472,69 @@ do not contain space or `"` characters) or quoted (`""`). Quoted arguments can include 'escaped' characters, escaped with an initial `\` character. +Account may need to be taken of the shell's approach to the processing of +command line arguments. For example, to pass `'a single quoted string'`: + +=== "Unix-like (Bash or Zsh)" + + In Bash, or Zsh (if `RC_QUOTES` option not set): + + `stack bench --benchmark-arguments \"\''a single quoted string'\'\"` + + Outside of single quotes, `\"` escapes a double quote and `\'` escapes a + single quote. The content of single quotes is taken literally, but cannot + contain a single quote. + + In Zsh (if `RC_QUOTES` option set): + + `stack bench --benchmark-arguments '"''a single quoted string''"'` + + The content of single quotes is taken literally. Within single quotes, `''` + escapes a single quote. + +=== "Windows (PowerShell)" + + `stack bench --benchmark-arguments '"''a single quoted string''"'` + + The content of single quotes is taken literally. Within single quotes, `''` + escapes a single quote. + ### `--exec` option -`stack build --exec "<command> [<argument(s)>]"` will run the specified command +`stack build --exec '<command> [<argument(s)>]'` will run the specified command after a successful build. Specified arguments are separated by spaces. Arguments can be unquoted (if they do not contain space or `"` characters) or quoted (`""`). Quoted arguments can include 'escaped' characters, escaped with an initial `\` character. +Account may need to be taken of the shell's approach to the processing of +command line arguments. For example, to pass `'a single quoted string'`: + +=== "Unix-like (Bash or Zsh)" + + In Bash, or Zsh (if `RC_QUOTES` option not set): + + `stack build --exec '<command> '\"\''a single quoted string'\'\"` + + Outside of single quotes, `\"` escapes a double quote and `\'` escapes a + single quote. The content of single quotes is taken literally, but cannot + contain a single quote. + + In Zsh (if `RC_QUOTES` option set): + + `stack build --exec '<command> "''a single quoted string''"'` + + The content of single quotes is taken literally. Within single quotes, `''` + escapes a single quote. + +=== "Windows (PowerShell)" + + `stack build --exec '<command> "''a single quoted string''"'` + + The content of single quotes is taken literally. Within single quotes, `''` + escapes a single quote. + ### `--test-arguments`, `--ta` option `stack build --test --test-arguments=<argument(s)>` will pass the specified @@ -446,6 +544,33 @@ Specified arguments are separated by spaces. Arguments can be unquoted (if they do not contain space or `"` characters) or quoted (`""`). Quoted arguments can include 'escaped' characters, escaped with an initial `\` character. + +Account may need to be taken of the shell's approach to the processing of +command line arguments. For example, to pass `'a single quoted string'`: + +=== "Unix-like (Bash or Zsh)" + + In Bash, or Zsh (if `RC_QUOTES` option not set): + + `stack test --test-arguments \"\''a single quoted string'\'\"` + + Outside of single quotes, `\"` escapes a double quote and `\'` escapes a + single quote. The content of single quotes is taken literally, but cannot + contain a single quote. + + In Zsh (if `RC_QUOTES` option set): + + `stack bench --benchmark-arguments '"''a single quoted string''"'` + + The content of single quotes is taken literally. Within single quotes, `''` + escapes a single quote. + +=== "Windows (PowerShell)" + + `stack test --test-arguments '"''a single quoted string''"'` + + The content of single quotes is taken literally. Within single quotes, `''` + escapes a single quote. ## Flags affecting GHC's behaviour
doc/debugging.md view
@@ -2,11 +2,19 @@ # Debugging -To profile a component of the current project, simply pass the `--profile` -flag to `stack`. The `--profile` flag turns on the `--enable-library-profiling` -and `--enable-executable-profiling` Cabal options _and_ passes the `+RTS -p` -runtime options to any testsuites and benchmarks. +To profile a component of the current project, pass the +[`--profile` flag](build_command.md#-profile-flag) to `stack build`. +The flag: + +* for project packages, turns on the Cabal flag + [`--enable-profiling`](https://cabal.readthedocs.io/en/stable/setup-commands.html#cmdoption-runhaskell-Setup.hs-configure-enable-profiling); +* turns on the Cabal flag + [`--enable-library-profiling`](https://cabal.readthedocs.io/en/stable/setup-commands.html#cmdoption-runhaskell-Setup.hs-configure-enable-library-profiling); and +* passes GHC's + [`+RTS -p` runtime options](https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#rts-flag--p) + to any test suites and benchmarks. + For example the following command will build the `my-tests` testsuite with profiling options and create a `my-tests.prof` file in the current directory as a result of the test run. @@ -24,13 +32,29 @@ ~~~ For more fine-grained control of compilation options there are the -`--library-profiling` and `--executable-profiling` flags which will turn on the -`--enable-library-profiling` and `--enable-executable-profiling` Cabal -options respectively. Custom GHC options can be passed in with -`--ghc-options "more options here"`. +[`--library-profiling` flag](build_command.md#-no-library-profiling-flag) and +[`--executable-profiling` flag](build_command.md#-no-executable-profiling-flag). +The `--library-profiling` flag: + +* turns on the Cabal flag + [`--enable-library-profiling`](https://cabal.readthedocs.io/en/stable/setup-commands.html#cmdoption-runhaskell-Setup.hs-configure-enable-library-profiling); and +* passes GHC's + [`+RTS -p` runtime options](https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#rts-flag--p) + to any test suites and benchmarks. + +The `--executable-profiling` flag: + +* for project packages, turns on the Cabal flag + [`--enable-profiling`](https://cabal.readthedocs.io/en/stable/setup-commands.html#cmdoption-runhaskell-Setup.hs-configure-enable-profiling); +* turns on the Cabal flag + [`--enable-library-profiling`](https://cabal.readthedocs.io/en/stable/setup-commands.html#cmdoption-runhaskell-Setup.hs-configure-enable-library-profiling); and +* passes GHC's + [`+RTS -p` runtime options](https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#rts-flag--p) + to any test suites and benchmarks. + To enable compilation with profiling options by default you can add the -following snippet to your `stack.yaml` or `~/.stack/config.yaml`: +following to a project-level or global YAML configuration file: ~~~yaml build:
doc/exec_command.md view
@@ -38,3 +38,29 @@ unquoted (if they do not contain space or `"` characters) or quoted (`""`). Quoted items can include 'escaped' characters, escaped with an initial `\` character. + +Account may need to be taken of the shell's approach to the processing of +command line arguments. For example, to pass `'a single quoted string'`: + +=== "Unix-like (Bash or Zsh)" + + In Bash, or Zsh (if `RC_QUOTES` option not set): + + `stack exec <command> -- \''a single quoted string'\'` + + Outside of single quotes, `\'` escapes a single quote. The content of single + quotes is taken literally, but cannot contain a single quote. + + In Zsh (if `RC_QUOTES` option set): + + `stack exec <command> -- '''a single quoted string'''` + + The content of single quotes is taken literally. Within single quotes, `''` + escapes a single quote. + +=== "Windows (PowerShell)" + + `stack exec <command> -- '''a single quoted string'''` + + The content of single quotes is taken literally. Within single quotes, `''` + escapes a single quote.
doc/new_command.md view
@@ -47,6 +47,11 @@ `--omit-packages` flags are as for the [`stack init` command](init_command.md). These arguments are ignored if the `--no-init` flag is passed. +If a snapshot is specified at the command line and the project is initialised +for use with Stack, `stack new` will try to use it. For further information, see +the documentation for the [`--snapshot`](global_flags.md#-snapshot-option) and +[`--resolver`](global_flags.md#-resolver-option) options. + ## Project templates A project template file can be located in a repository named `stack-templates`
doc/run_command.md view
@@ -9,13 +9,22 @@ ~~~ `stack run` builds a project executable and runs it. If the command has a first -argument and it is recognised as an executable target then that is built. -Otherwise, the project's first executable is built. If the project has no -executables Stack reports no executables found as an error. +argument and it is recognised as the name of an executable component of a +project package then that is built. Otherwise, the project's first executable is +built. If the project has no executables Stack reports no executables found as +an error. +!!! note + + To identify a project's first executable, and search for the name of an + executable component, Stack lists the executable components, in order, for + each package, listed in order. For example: + + `packageA:a-exe` < `packageA:b-exe` < `packageB:a-exe` < `packageB:b-exe` + Everything after `--` on the command line is interpreted as a command line argument to be passed to what is run, other than a first argument recognised as -an executable target. +the name of an executable component of a project package. By default:
doc/stack_root.md view
@@ -166,9 +166,18 @@ ### `pantry\hackage` directory -This contains the package index. If the contents of the directory are deleted, -and Stack needs to consult the package index, Stack will seek to download the -latest package index. +This contains a local cache of the package index. If the contents of the +directory are deleted, and Stack needs to consult the package index, Stack will +seek to download the latest package index. + +!!! info + + Stack depends on package `pantry` which, in turn, depends on package + `hackage-security`. The latter handles the local cache of the package index. + The type `CacheLayout` represents the location of the files that are cached. + `pantry` uses `cabalCacheLayout :: CacheLayout`, the layout that Cabal (the + tool) uses. That is what specifies the names of the files used to cache the + package index, including `00-index.tar` and `00-index.tar.gz`. ### `pantry` directory
doc/upload_command.md view
@@ -70,7 +70,7 @@ For further information about how to create such an archive file, see the documentation for the -[`stack haddock --haddock-for-hackage`](build_command.md#-no-haddock-for-haddock-flag) +[`stack haddock --haddock-for-hackage`](build_command.md#-no-haddock-for-hackage-flag) command. If `ITEM` is a relative path to a package directory,
doc/yaml_configuration.md view
@@ -1886,10 +1886,18 @@ ~~~yaml urls: - latest-snapshot: https://www.stackage.org/download/snapshots.json + latest-snapshot: https://stackage-haddock.haskell.org/snapshots.json ~~~ Customize the URLs where Stack looks for snapshot build plans. + +!!! note + + The default for Stack 1.3.0 to 2.15.3 was + https://s3.amazonaws.com/haddock.stackage.org/snapshots.json. Following the + handover of the Stackage project to the Haskell Foundation in + early 2024, the file at that URL may not be up to date. Users of those + versions of Stack should configure the URL to be the default above. ### with-gcc
src/Stack/Build/ExecuteEnv.hs view
@@ -132,6 +132,7 @@ , setupExe :: !(Maybe (Path Abs File)) -- ^ Compiled version of eeSetupHs , cabalPkgVer :: !Version + -- ^ The version of the compiler's Cabal boot package. , totalWanted :: !Int , locals :: ![LocalPackage] , globalDB :: !(Path Abs Dir) @@ -148,6 +149,15 @@ -- ^ Value of the PATH environment variable } +-- | Type representing setup executable circumstances. +data SetupExe + = SimpleSetupExe !(Path Abs File) + -- ^ The build type is Simple and there is a path to an existing setup + -- executable. + | OtherSetupHs !(Path Abs File) + -- ^ Other circumstances with a path to the source code for the setup + -- executable. + buildSetupArgs :: [String] buildSetupArgs = [ "-rtsopts" @@ -677,13 +687,13 @@ } menv <- liftIO $ config.processContextSettings envSettings distRelativeDir' <- distRelativeDir - esetupexehs <- + setupexehs <- -- Avoid broken Setup.hs files causing problems for simple build -- types, see: -- https://github.com/commercialhaskell/stack/issues/370 case (package.buildType, ee.setupExe) of - (C.Simple, Just setupExe) -> pure $ Left setupExe - _ -> liftIO $ Right <$> getSetupHs pkgDir + (C.Simple, Just setupExe) -> pure $ SimpleSetupExe setupExe + _ -> liftIO $ OtherSetupHs <$> getSetupHs pkgDir inner $ \keepOutputOpen stripTHLoading args -> do let cabalPackageArg -- Omit cabal package dependency when building @@ -725,11 +735,10 @@ getPackageArgs :: Path Abs Dir -> RIO env [String] getPackageArgs setupDir = case package.setupDeps of - -- The package is using the Cabal custom-setup - -- configuration introduced in Cabal 1.24. In - -- this case, the package is providing an - -- explicit list of dependencies, and we - -- should simply use all of them. + -- The package is using the Cabal custom-setup configuration + -- introduced in Cabal 1.24. In this case, the package is + -- providing an explicit list of dependencies, and we should + -- simply use all of them. Just customSetupDeps -> do unless (Map.member (mkPackageName "Cabal") customSetupDeps) $ prettyWarnL @@ -792,20 +801,30 @@ -- explicitly requested in the stack.yaml file. Nothing -> do warnCustomNoDeps - pure $ - cabalPackageArg + let packageDBArgs' = case package.buildType of + -- The Configure build type is very similar to Simple. As + -- such, Stack builds the setup executable in much the + -- same way as it would in the case of Simple. + C.Configure -> + [ "-hide-all-packages" + , "-package base" + ] -- NOTE: This is different from packageDBArgs above in -- that it does not include the local database and does -- not pass in the -hide-all-packages argument - ++ ( "-clear-package-db" - : "-global-package-db" - : map - (("-package-db=" ++) . toFilePathNoTrailingSep) - ee.baseConfigOpts.extraDBs - ++ [ "-package-db=" - ++ toFilePathNoTrailingSep ee.baseConfigOpts.snapDB - ] - ) + _ -> + map + (("-package-db=" ++) . toFilePathNoTrailingSep) + ee.baseConfigOpts.extraDBs + <> [ "-package-db=" + <> toFilePathNoTrailingSep ee.baseConfigOpts.snapDB + ] + pure $ + [ "-clear-package-db" + , "-global-package-db" + ] + <> packageDBArgs' + <> cabalPackageArg setupArgs = ("--builddir=" ++ toFilePathNoTrailingSep distRelativeDir') : args @@ -869,9 +888,9 @@ ExcludeTHLoading -> ConvertPathsToAbsolute KeepTHLoading -> KeepPathsAsIs - exeName <- case esetupexehs of - Left setupExe -> pure setupExe - Right setuphs -> do + exeName <- case setupexehs of + SimpleSetupExe setupExe -> pure setupExe + OtherSetupHs setuphs -> do distDir <- distDirFromDir pkgDir let setupDir = distDir </> relDirSetup outputFile = setupDir </> relFileSetupLower @@ -883,32 +902,32 @@ compilerPath <- view $ compilerPathsL . to (.compiler) packageArgs <- getPackageArgs setupDir runExe compilerPath $ - [ "--make" - , "-odir", toFilePathNoTrailingSep setupDir - , "-hidir", toFilePathNoTrailingSep setupDir - , "-i", "-i." - ] ++ packageArgs ++ - [ toFilePath setuphs - , toFilePath ee.setupShimHs - , "-main-is" - , "StackSetupShim.mainOverride" - , "-o", toFilePath outputFile - , "-threaded" - ] ++ - + [ "--make" + , "-odir", toFilePathNoTrailingSep setupDir + , "-hidir", toFilePathNoTrailingSep setupDir + , "-i", "-i." + ] + <> packageArgs + <> [ toFilePath setuphs + , toFilePath ee.setupShimHs + , "-main-is" + , "StackSetupShim.mainOverride" + , "-o", toFilePath outputFile + , "-threaded" + ] -- Apply GHC options -- https://github.com/commercialhaskell/stack/issues/4526 - map - T.unpack - ( Map.findWithDefault - [] - AGOEverything - config.ghcOptionsByCat - ++ case config.applyGhcOptions of - AGOEverything -> ee.buildOptsCLI.ghcOptions - AGOTargets -> [] - AGOLocals -> [] - ) + <> map + T.unpack + ( Map.findWithDefault + [] + AGOEverything + config.ghcOptionsByCat + <> case config.applyGhcOptions of + AGOEverything -> ee.buildOptsCLI.ghcOptions + AGOTargets -> [] + AGOLocals -> [] + ) liftIO $ atomicModifyIORef' ee.customBuilt $ \oldCustomBuilt ->
src/Stack/Config.hs view
@@ -297,8 +297,19 @@ ) in maybe (pure relDirStackWork) (liftIO . parseStackWorkEnv) mstackWorkEnv let workDir = fromFirst configWorkDir0 configMonoid.workDir + -- The history of the URL below is as follows: + -- + -- * Before Stack 1.3.0 it was + -- https://www.stackage.org/download/snapshots.json. + -- * From Stack 1.3.0 to 2.15.3 it was + -- https://s3.amazonaws.com/haddock.stackage.org/snapshots.json. The + -- change was made because S3 was expected to have greater uptime than + -- stackage.org. + -- * In early 2024, the Stackage project was handed over to the Haskell + -- Foundation. Following that handover, the URL below was considered + -- the most reliable source of the file in question. latestSnapshot = fromFirst - "https://s3.amazonaws.com/haddock.stackage.org/snapshots.json" + "https://stackage-haddock.haskell.org/snapshots.json" configMonoid.latestSnapshot clConnectionCount = fromFirst 8 configMonoid.connectionCount hideTHLoading = fromFirstTrue configMonoid.hideTHLoading
stack.cabal view
@@ -1,6 +1,6 @@ cabal-version: 2.0 name: stack-version: 2.15.3+version: 2.15.5 license: BSD3 license-file: LICENSE maintainer: manny@fpcomplete.com@@ -404,7 +404,7 @@ neat-interpolation >=0.5.1.4, open-browser >=0.2.1.0, optparse-applicative >=0.18.1.0,- pantry >=0.9.3.2,+ pantry >=0.9.3.2 && <0.10.0, path >=0.9.5, path-io >=1.8.1, persistent >=2.14.0.0 && <2.15,@@ -531,7 +531,7 @@ neat-interpolation >=0.5.1.4, open-browser >=0.2.1.0, optparse-applicative >=0.18.1.0,- pantry >=0.9.3.2,+ pantry >=0.9.3.2 && <0.10.0, path >=0.9.5, path-io >=1.8.1, persistent >=2.14.0.0 && <2.15,@@ -640,7 +640,7 @@ open-browser >=0.2.1.0, optparse-applicative >=0.18.1.0, optparse-generic >=1.5.2,- pantry >=0.9.3.2,+ pantry >=0.9.3.2 && <0.10.0, path >=0.9.5, path-io >=1.8.1, persistent >=2.14.0.0 && <2.15,@@ -764,7 +764,7 @@ neat-interpolation >=0.5.1.4, open-browser >=0.2.1.0, optparse-applicative >=0.18.1.0,- pantry >=0.9.3.2,+ pantry >=0.9.3.2 && <0.10.0, path >=0.9.5, path-io >=1.8.1, persistent >=2.14.0.0 && <2.15,