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

Cabal: Allow Win32-2.14

testsuite: Fix hardcoded /bin/bash in custom-cc wrapper

Matthew Pickering authored 1 year ago and Artem Pelenitsyn committed 1 year ago

Not all operating systems have `/bin/bash` available, it is more portable
to use `/usr/bin/env bash`

For example: https://stackoverflow.com/questions/21612980/why-is-usr-bin-env-bash-superior-to-bin-bash

* Fixup #9614: make config file extraction from help text more robust

The previous test (PR #9614) did not work when the config file was
absent, because then the help text would add one more line at the
end (see issue #535).

The new test looks for the exact line printed before the line with the
config file.

We test both scenarios, with config file present or absent.

* Trim lines before searching the marker to work around CRLF issues.

---------

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

Bumps [haskell-actions/run-fourmolu](https://github.com/haskell-actions/run-fourmolu) from 9 to 10.
- [Release notes](https://github.com/haskell-actions/run-fourmolu/releases)
- [Changelog](https://github.com/haskell-actions/run-fourmolu/blob/master/CHANGELOG.md)
- [Commits](https://github.com/haskell-actions/run-fourmolu/compare/v9...v10

)

---
updated-dependencies:
- dependency-name: haskell-actions/run-fourmolu
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Add further tests of cyclical project imports

Refactor the core component building logic: gbuild vs buildOrReplLib

1. Refactors the duplicated `buildExtraSources` function from `gbuild` and
    `buildOrReplLib` into a standalone monadic computation in the context of
    building a component. This refactor allows
    us to share the code for building an extra source amongst the two
    functions.

2. Creates a new module Distribution.Simple.GHC.Build.Modules which, in the
    same spirit as ...GHC.Build.ExtraModules, defines an action which builds
    all the Haskell modules of the component being built.

    This function clarifies and re-implements the logic of building Haskell
    modules in the different possible ways, while accounting for
    Template Haskell special "way requirements", which was previously
    duplicated in a non-obvious manner in gbuild and buildOrReplLib.

    The Note [Building Haskell modules accounting for TH] in that module
    explains the big picture, and the implementation is re-done in light of
    it.

3. Re-work the linker invocations, focusing on preserving existing
behaviour before simplifying or fixing bugs any further.

Fixes #9389.

- Assert on exact cyclical import failure message
- Add logging and assertOutputContains to cyclical tests
- Use a different naming convention for cyclical import tests
- Use "self" in naming
- Show import tree

Don't build unnecessary targets of legacy-fallback deps.