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.

Bump a number of dependencies

Add instruction for CI patches

Add static pre-release job

Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>

Add a job that builds a statically linked cabal-install executable, and
make it available for pre-releases.

Resolves #9631.

Add tests for project imports and constraint version conflicts

Don't inherit package database to tests

We were attempting to register a package into the global package
database, which then triggered some other check to do with relocatable
packages to fail.

The fix is to initialise and use a local package database, so the
package would be built and installed into the local package database.

I can't think of a reason why it would be desirable to expose the user's
cabal store or local dist-newstyle to the test runner. In fact, this can
break test output in certain situations depending on what is in your
store.

Tests should run in as hemertic environment as possible and not
depend on anything to do with external system configuration.

I have introduced a Note [Testsuite package environments] which explains
what the environments are for the three different components of the
testsuite.

{- Note [Testsuite package environments]

There are three different package environments which are used when running the
testsuite.

1. Environment used to compile `cabal-tests` executable
2. Environment used to run test scripts "setup.test.hs"
3. Environment made available to tests themselves via `./Setup configure`

These are all distinct from each other and should be specified separately.

Where are these environments specified:

1. The build-depends on `cabal-tests` executable in `cabal-testsuite.cabal`
2. The build-depends of `test-runtime-deps` executable in `cabal-testsuite.cabal`
   These dependencies are injected in a special module (`Test.Cabal.ScriptEnv0`) which
   then is consulted in `Test.Cabal.Monad` in order to pass the right environmnet.
   This is mechanism by which the `./Setup` tests have access to the in-tree `Cabal`
   and `Cabal-syntax` libraries.
3. No specification, only the `GlobalPackageDb` is available (see
   `testPackageDBStack`) unless the test itself augments the environment with
   `withPackageDb`.

At the moment, `cabal-install` tests always use the bootstrap cabal, which is a
bit confusing but `cabal-install` is not flexible enough to be given additional
package databases (yet).

-}

- Allow for bad behaviour of master branch
- Add cyclical checks with same file names and hops
- Add cyclical import tests with 1 and 2 hops in cycle
- Expected output has project with full project path
- Add newlines at EOF