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.

The refactor in f70fc980 solved an
inconsistency in `buildAndInstallUnpackedPackage`. Namely, before the
refactor, we didn't pass `hsSetupBuildArgs` to the build invocations,
and afterwards we did.

The result is that build targets of (legacy) package `B`, that a package
`A` depends on, are now passed to the ./Setup build invocation of
package `B` (e.g. `./Setup build lib:openapi3` rather than just `./Setup
build`).

This means we no longer /build always all targets of a legacy-package/
(for example, the lib, the testsuites and the executables).
Instead only the required target (just the lib) will be built.

However, despite now passing the build args to `./Setup build`, we
weren't passing the same arguments to the `./Setup copy` invocation.
Therefore, `./Setup copy` would also try to copy targets of the package
that weren't built, resulting in a failure.

This fixes that failure by correctly passing the build targets to the
`./Setup copy` invocation, just like we do for the `./Setup build` one.

Fixes #9640