GitLab

Sandboxes are obsolete with the launch of Nix-style/new-/v2 commands, and thus
should not be given high visibility in the docs for the current version. If docs
are needed then the docs for a previous version of cabal can be used.

[ci skip]

Resolve #6359

`preferred-versions` are left out for now.
It shouldn't be difficult to add, but needs work nevertheless.

We also allow relative paths, which kind of work,
if you are careful.

In addtition
- change the index cache to use `Distribution.Utils.Structured`,
  making Binary instances generically derived.
- separate Distribution.Client.HashValue into own module.
  This allows to use HashValue for hashing the part of localRepoPath
  (breaks module dependency cycle).

Almost as a feature generated 01-index.cache is never updated.
If you change the contents of the directory, you have to purge
01-index.cache file yourself.

This implements lots of plumbing to allow the `--benchmark-option(s)`
flags to be used with `v2-bench`, analgous to `v2-test`'s
`--test-option(s)` flag.

Fixes #6209.

Corrected a typo.

Spotted by @matthewbauer.

[ci skip]

Also update the docs for `--enable-executable-dynamic`
as they were slightly misleading.

[ci skip]

On all platforms, warn about their presence. On Windows, we should use
slashes (as opposed to backslashes) where possible, to avoid causing
things like #5386.

Closes #5386.

# Conflicts:
#	Cabal/Distribution/PackageDescription/Check.hs
#	Cabal/Distribution/PackageDescription/Parsec/FieldDescr.hs
#	Cabal/Distribution/Parsec/Types/FieldDescr.hs
#	Cabal/doc/developing-packages.rst

Also rename config field configArDoesNotSupportResponseFiles into
configUseResponseFiles

Newer versions of ar program support @file argument, which allows to
supply all object files, however numerous, in one call to ar, thus
reducing overhead of creating multiple ar processes where each process
must fully re-read output of the previous invocation.

(cherry picked from commit 32fe4200)

(cherry picked from commit 261e5eb4)

For example, "setup.Cabal installed" forces cabal to use the installed Cabal
library for all setup scripts.

For example, --constraint="any.pkg == 5" applies to "pkg" whether it is a
top-level dependency, setup dependency, or build tool dependency.

I also modified the UserConstraint type so that it is more similar to the
PackageConstraint type, now that both types need to express similar
"constraint scopes".

This commit comments out the part of #4219 that parses build tool dependency
qualifiers, to disable the feature until we finalize the syntax. It also comments
out the part of #4236 that tests the parsing.

I also moved all the detail about constraint syntax that was in
the Nix-style local build cabal.project section into the section
on the --constraint command line option. This reduces some
duplication of information.

`build-tools` is described in terms of `build-tool-depends`, just as it is
implemented in terms of it.

`--dynlibdir` indicates the directory in which dynamic libraries
are installed. By default this setting is equal to:

`$libdir/$abi`

The static libraries will still end up in:

`$libdir/$libsubdir`

With `$libsubdir/$abi` as the default directory for dynamic
libraries, dynamic libraries will by default end up in a
single shared directory (per package database). This has the
potential to reduce start-up times for dynamically linked
executable as only one RPATH per package database will be
needed.

This commit uses the functionality defined in

https://phabricator.haskell.org/D2611

to tell GHC's > 8.0.1 package database that dynamic libraries
are copied to the directories mentioned in the

`dynamic-library-dirs`

field.

[ci skip]