testsuite: Run tests in temporary system directories

1. Working directory is not contaminated with results of the testsuite.
   Tests can be written in a more liberal way (creating/writing files
   etc).
2. The tests are more hermetic.. for example it was basically impossible
   to write a test which run outside of a project context.
3. The overall path lengths will be much shorter, which has been a
   consistent issue on windows. We can remove hacks like
   `withShorterPathForNewBuildStore`.

Fixes #9711

Download stackage.org/.../cabal.config locally

cabal-install: Clarify the semantics of package-db flag

In this PR we make the `--package-db` flag apply only to the default
immutable initial package stack rather than also applying to the store
package database.

There are two special package databases which cabal install knows about
and treats specially.

* The store directory, a global cache of installed packages where cabal
  builds and installs packages into.
* The inplace directory, a local build folder for packages, where cabal
  builds local packages in.

It is very important that cabal registers packages it builds into one of
these two locations as there are many assumptions that packages will end
up here.

With the current design of the `--package-db` flag, you are apparently
allowed to override the store location which should have the effect of
making the last package database in the package stack the "store"
directory. Perhaps this works out in theory but practically this
behaviour was broken and things were always registered into the store
directory that cabal knew about. (The assertion in
`ProjectBuilding.UnpackedPackage` was failing (see added test)).

With `--package-db` not being able to modify the location of the store
directory then the interaction of `--package-db`, `--store-dir` and
`--dist-dir` flags become easy to understand.

* `--package-db` modify the initial package database stack, these
  package database will not be mutated by cabal and provide the initial
  package environment which is used by cabal.
* `--store-dir` modify the location of the store directory
* `--dist-dir` modify the location of the dist directory (and hence
  inplace package database)

Treating the flags in this way also fix an assertion failure when
building packages.

Fixes #9678

CI updates (drop 8.4.4, update old-ghcs, update bootstrap plans)

It fails in the old-ghcs 8.4.4 configuration, and debugging why seems to
have very little pay-off for this niche feature in a very old
configuration.

And add the relevant CI jobs for these plans

We were missing coverage from running tests with these ghc versions.

We no longer support 8.4.4 as it is older than three years.
cabal-install can
still be used with 8.4.4, but just not built with it, and this is tested
by the old-ghcs jobs.

add the extension ListTuplePuns (GHC proposal 475)

Fix #9534 Add constructor `PPC64LE` to type `Arch`, for powerpc64le

Also makes consequent changes.

Fix multi-repl closure computation with invalid Custom setup

This patch deletes a lot of hairy logic to do with removing "bad" edges
from the closure. Now the solver just forces `Cabal >= 3.11` universally
when `--enable-multi-repl` is enabled.

Fixes #9710

Modularise writeAutogenFiles

This commit modularises the logic for generation of autogenerated files
and autogenerated modules.

This commit adds a Suffix newtype to describe suffixes as handled
by suffix handlers & preprocessors, and changes the PPSuffixHandler
type definition to use it.

It also moves some type definitions from Distribution.Simple.PreProcess
to the new module Distribution.Simple.PreProcess.Types.

As this commit changes the definition of PPSuffixHandler, it will
break custom Setup scripts which use the 'hookedPreProcessors'
functionality.

Add test cabal install remote-pkg for #9697

In #9697 we fixed passing local options to cabal install targets, but
rebasing accidentally dropped one of the added the tests for that PR,
which tested cabal install <target>, where <target> was only available
from a remote repository.

cabal-install: justify why legacy-fallback is used

This commit makes it so that cabal-install can explain the reason why
it used the legacy fallback, instead of building per-component.

Refactor CmdInstall / fix bug in #9697

CmdInstall.installAction is ~300 lines long and full of nested scopes
and ad-hoc logic. This change hopes to make it more readable and
understandable.

- Lift withProject and withoutProject out of installAction and split
  their relative concerns. E.g. not parsing URIs is installAction's
  concern not withProject's (which would just return a constant []).
- Split an intermediate step into a separate function, resolveTargetSelectorsInProjectBaseContext.
- Reuse withGlobalConfig and specFromPkgId (renamed from pidPackageSpecifiers).
- Avoid trying withProject a second time in case no target is specified.
- Fix a bug introduced in 802a326f where
  establishProjectBaseContext is called in a non-project setting. Also
  simplify its original implementation by moving the change into
  withProject rather than calling establishProjectBaseContext a second
  time.
- Document the interaction between cabal v2-install and local configuration
  and add few comments.

Merge two Globbing Modules and Fix #5349

We use the datatype representation from the globbing in cabal-install,
but preserve a standalone parser for globs present in cabal files, whose
specification is constrained by the cabal specification. The
implementations are merged taking the best parts of each.

We also make sure sdist is robust to accidentally-listed directories,
as the refactor of the globbing modules re-uncovered this issue, and
required a prompt fix for the refactor not to break some things.

Fixes #5349

* Add -Wunused-packages to the packages

Cabal, Cabal-syntax, cabal-install, cabal-install-solver

* Remove unused text dependency

* remove unguarded warning

* Remove 8.10 condition for unused-packages

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* Generate changelogs

Co-authored-by: Hécate Moonlight <Kleidukos@users.noreply.github.com>

Allow zlib-0.7

Ignore test T7339 output, libhello.so

Apply local configuration to install targets

The target of `cabal install` is not considered to be a local package,
which means local configuration (e.g. in cabal.project, or flags like
--enable-profiling) does not apply to it.

In 76670ebd, we changed the behaviour to
applying the local flags to cabal install targets, but it used the
literal target string as a package name to which the flags were
additionally applied.

However, `cabal install` targets are NOT necessarily package names, so,
e.g., if we did `cabal install exe:mycomp`, the local flags would not
apply since "exe:mycomp" is not a recognized /package/.

The solution is to parse the target selectors first, and apply the local
flags to the package of the resolved targets.

Fixes #7297, #8909, the install part of #7236, #8529, #7832

Revert "Drop sub-component targets (#8966)"

Hannes Siebenhandl authored 1 year ago and Mikolaj Konarski committed 1 year ago

This reverts commit 3f4c81fd.