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

This change removes support for building sub-component targets in
cabal-install, since no versions of Cabal support this feature.

The test RunMainBad is also dropped because without the concept of a
file target, RunMainBad is the same test as ScriptBad.

This complements the previous commit in order to fix #9326

- This allows the use of several **API incompatible builds of the same
  version of GHC** without corrupting the cabal store.
- This relies on the "Project Unit Id" which is available since GHC
  9.8.1, older versions of GHC do not benefit from this change.

[fixes #8114]

Similarly to CmdExec and CmdTest, get paths to all dependency binaries
and add those to PATH. Unlike CmdExec, add just the explicitly required
paths.

Extra prog paths were being handled in many different ways all thorugh
the codebase. This PR introduces a unified way to look at them.

Aiming for traceability, the addition of extra paths is now traced via
`logExtraProgramSearchPath`. All appearances of
`modifyProgramSearchPath` are replaced with `appendProgramSearchPath`
which traces the added paths.

`progInvokePathEnv` was only being set by GHC for some paths to
executables in components and only under certain circumstances. Now
every `ghcInvocation` sets the extra paths directly into `pkgInvokeEnv`.

In particular this fixes PATH issues when running MinGW cabal in
PowerShell, as usually for other OSes the system path contains most of
the expected directories.

In f70fc980, while refactoring
buildInplaceUnpackedPackage and buildAndInstallUnpackedPackage, we
started logging into a file on both cases, instead of logging to a file
only for buildAndInstallUnpackedPackage.

When building a package inplace, it is much more useful to be able to
see the GHC invocation directly outside of a log file.

This is especially relevant for Cabal developers working inplace.

Fixes #9606

This commit leverages the changes to the LocalBuildInfo datatype in
the Cabal library to reduce code duplication. Specifically, we split
off certain fields of ElaboratedConfiguredPackage by re-using the
BuildOptions datatype.

This is purely an internal refactoring with no observable changes
in behaviour.

The aim of this commit is to modularise LocalBuildInfo to better
reflect implicit invariants.

The top-level split

  data LocalBuildInfo =
    NewLocalBuildInfo
      { localBuildDescr  :: LocalBuildDescr
      , localBuildConfig :: LocalBuildConfig
      }

reflects which part of a LocalBuildInfo are set in stone by Cabal
(the LocalBuildDescr), while LocalBuildConfig contains options that
can be controlled/modified by the user in some way.

The split

  data LocalBuildDescr =
    LocalBuildDescr
    { packageBuildDescr :: PackageBuildDescr
    , componentBuildDescr :: ComponentBuildDescr
    }

reflects that some parts of the information determined at configuration
time resides at the package level, while other pieces of information
are pertinent to individual components.

Finally the structure of LocalBuildConfig is aimed to reduce code
duplication between the Cabal library and cabal-install.

* Introduce `-i/--ignore` command-line option.
    e.g.  cabal check --ignore=missing-upper-bounds  will not display
    “Missing upper bounds” warnings.

* Additionally, a filterPackageChecksById function is now exported
  in Distribution.PackageDescription.Check.Warning; this can be
  used by third party tools.

* Add CheckExplanationIDString to `cabal check` messages.
    e.g. from
      Error: The 'license' field is missing or is NONE.
    to
      Error: [license-none] The 'license' field is missing or is NONE.

    This makes using the cabal check `--ignore` option more immediate.

* Spool `MissingField` into separate constructors.
  Introducing five new constructors for `CheckExplanation`
    MissingFieldCategory
    MissingFieldMaintainer
    MissingFieldSynopsis
    MissingFieldDescription
    MissingFieldSynOrDesc
  This provides better ergonomic for `cabal check --ignore` and makes
  it easier to update the manual if the need arises.

* Add tests for desiderable `--ignore` string qualities (not too long,
  without too many '-', unique).

* Warn when `--ignore` string is not recognised.
    Also add a test for this.

* Add documentation.

* Add changelog.

When using the multi components repl, the last unit given to ghc
is the active unit. This change uses the cabal repl argument
order instead of relying on the 'listDirectory' ordering.

This refactor of Distribution.Client.ProjectBuilding does the following:

* Moves package file monitoring logic to
  Distribution.Client.ProjectBuilding.PackageFileMonitor

* Moves the `buildInplaceUnpackedPackage` and
  `buildAndInstallUnpackedPackage` with auxiliary functions to
  Distribution.Client.ProjectBuilding.UnpackedPackage

* Refactors the common bits of `buildInplaceUnpackedPackage` and
  `buildAndInstallUnpackedPackage` to remove considerable code
  duplication while simplifying and making both functions more
  structured.

Namely, to better structure build inplace vs build and install, I've
introduced:

* `PackageBuildingPhase` describes the various phases of processing the
  unpacked package both inplace and on install
    * Configure
    * Build
    * Install (copy + register)
    * Test
    * Bench
    * Repl
    * Haddock

* Then, `buildAndRegisterUnpackedPackage` implements the common logic
  between the two functions (such as calls to ./Setup and the order of
  the phases) but delegates the logic specific to each phase to an
  argument function which maps `PackageBuildingPhase` to `IO` actions.

* Now, build inplace and build and install functions are comprised as:
    * A wrapper around `buildAndRegisterUnpackedPackage` which does
      things specific to each before and after the main phases are
      processed
    * A delegate function which maps an action to each package
      processing phase

Fixes #9499

f-a authored 1 year ago and f-a committed 1 year ago

* Add a `Compat` module to accomodate two different `tar` interfaces.
* Tweak `-Wunused-packages` conditional (thanks Phil de Joux)

This commmit removes the dependency of the
Distribution.Simple.Program.Types on Distribution.Simple.Program.Find
by shuffling around a few definitions between the modules.

This makes the "Types" module more self-contained, which means it
can be more easily imported without causing module cycles.

This commit re-designs the mechanism by which we make the .mix files of
libraries available to produce the Haskell Program Coverage report after
running testsuites.

The idea, for the Cabal library, is:

* Cabal builds libraries with -fhpc, and store the hpc artifacts in
  build </> `extraCompilationArtifacts`
* At Cabal install time, `extraCompilationArtifacts` is copied into the
  package database
* At Cabal configure time, we both
    - receive as --coverage-for flags unit-ids of library components
      from the same package (ultimately, when #9493 is resolved, we will
      receive unit ids of libraries in other packages in the same
      project too),
    - and, when configuring a whole package instead of just a testsuite
      component, we determine the unit-ids of libraries in the package
  these unit-ids are written into `configCoverageFor` in `ConfigFlags`
* At Cabal test time, for each library to cover (stored in
  `configCoverageFor`), we look in the package database for the hpc
  dirs, which we eventually pass along to the `hpc markup` call as
  `--hpcdir` flags

As for cabal-install:

* After a plan has been elaborated, we select the packages which can be
  covered and pass them to Cabal's ./Setup configure as
  --coverage-for=<unit-id> flags.
    - Notably, valid libraries are non-indefinite and
      non-instantiations, since HPC does not support backpack.
    - Furthermore, we only include libraries in the same package as the
      component being configured, despite possibly there being
      more library components in other packages of the same project.
      When #9493 is resolved, we could lift this restriction and pass
      all libraries local to the package as --coverage-for. See
      `determineCoverageFor` and `shouldCoverPkg` in Distribution.Client.ProjectPlanning.

Detail:
    We no longer pass the path to the testsuite's mix dirs to `hpc
    markup` because we only ever include modules in libraries, which
    means they were previously unused.

Fixes #6440 (internal libs coverage), #6397 (backpack breaks coverage),
doesn't yet fix #8609 (multi-package coverage report) which is tracked
in #9493, and fixes in a new way the previously fixed #4798, #5213.

This commits re-enables per-component builds when coverage checking is
enabled. This restriction was previously added in #5004 to fix #4798.

- #4798 was subsequently fixed "again" with the fix for #5213, in #7493 by
fixing the paths of the testsuite `.mix` files to the same location as
that of the main library component.

Therefore the restriction to treat testsuites per-package
(legacy-fallback) is no longer needed.

We went further and fixed coverage for internal sublibraries, packages
with backpack (but without generating coverage information for
indefinite and instantiated units -- it is not clear what it would mean
for HPC to support this), and coverage for multi-package projects.

1. We allow hpc in per-component builds

2. To generate hpc files in the appropriate component directories in the
distribution tree, we remove the hack from #7493 and instead determine
the `.mix` directories that are included in the call to `hpc markup` by
passing the list of components in the project from the cabal-install
invocation of test.
We also drop an unnecessary directory in the hpc file hierarchy.

3. To account for internal (non-backpack) libraries, we include the mix
   dirs and modules of all (non-indefinite and non-instantiations)
   libraries in the project

   Indefinite libraries and instantiations are ignored as it is not
   obvious what it means for HPC to support backpack, e.g. covering a
   library function that two different instantiations

4. We now only reject coverage if there are no libraries at all in the
   project, rather than if there are no libraries in the package.

This allows us to drop the coverage masking logic in
cabal.project.coverage while still having coverage of cabal-install
(i.e. cabal test --enable-coverage cabal-install now works without the
workaround)

Even though we allow multi-package project coverage, we still cover each
package independently -- the tix files resulting from all packages are
not combined for the time being.

Multi-package project coverage is fixed in Cabal, however, the
paths to the source files listed in the `.mix` files will be incorrect
because package sources will no longer be in the root of the project
tree, but rather under the subdir with the package. We add an error for
multi-package projects when coverage is enabled, and track lifting this
error in #9493.

Includes tests for #6440, #6397, #8609, and #4798 (the test for #5213 already exists)

Fixes #6440 (internal libs coverage), #6397 (backpack breaks coverage)
, doesn't yet fix #8609 (multi-package coverage report) and fixes in a new way the
previously fixed #4798, #5213.

* Add `cabal-version` 3.12

* Add test for #9331

- `cabal check`: Guard Paths_* behind `cabal-version: 3.12` or higher,
  “fail” and “succeed” tests.
- `cabal build`: Guard Paths_* behind `cabal-version: 3.12` or higher,
  “fail” test.

* Guard PackageInfo behind cabal-version ≥ 3.12

---------

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

As prompted to do so in review

As requested in review

* Add symlinkableBinary
* Extract installExesPrep
* Add data InstallExe and data Symlink
* Replace symlinkable with symlink taking InstallExe
* Replace symlink/copy as symlink or copy
* Improve a haddock, from check to try and stop
* Get rid of duplication between install*Exes
* Add InstallCfg
* Drop the cfg prefix
* Make errorMessage a where nested local
* Add haddocks to InstallCheck

ProjectPlanning is a big module, counting more than 4k lines.

This change separates the code related to the setup policy to its own
module and tidies up a bit the documentation of ProjectPlanning.

This makes `checkTarget` a little smarter by deduplicating the
`TargetPackage` so as not to error out when the user has the line

    package: .

twice in their `cabal.project`.

Fixes #9448

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

* rm Log from Severity loglevels

* replace Log with Info

* add changelog

* fix typo

* fix changelog entry

* add displaySeverity

* fix changelog

* run fourmolu

* implement case expression in displaySeverity

Issue #9334 shows that `%` characters on Windows result in invalid
paths, also `/` characters on Linux create invalid paths.

This changes from using base64 to using base16 with the same length
we use for unit-ids.

* Remove 'CommandDelegate' in favour of abstracting the fallback in
  'commandsRun', there is a new variant 'commdandRunWithFallback' which
  takes a continuation
  - This restores the modularity between the `Cabal` library and
    `cabal-install` as now `Cabal` doesn't need to know anything about
    the external command interface.
  - Fixes #9403
* Set the $CABAL environment variable to the current executable path
  - This allows external commands to be implemented by calling $CABAL,
    which is strongly preferred to linking against the Cabal library as
    there is no easy way to guantee your tool and `cabal-install` link
    against the same `Cabal` library.
  - Fixes #9402
* Pass the name of the argument
  - This allows external commands to be implemented as symlinks to an
    executable, and multiple commands can be interpreted by the same
    executable.
  - Fixes #9405
* `cabal help <cmd>` is interpreted as `cabal-<cmd> --help` for external
  commands.
  - This allows the `help` command to also work for external
  commands and hence they are better integrated into cabal-install.
  - Fixes #9404

The tests are updated to test all these additions.

These features bring the external command interface up to par with the
cargo external command interface.

The `setDocumentation` function was modifying the elaborated package
after the hash was computed. This led to the assertion failing as the
computed hash was different to what was computed in the initial install
plan.

Therefore in order to fix this we either needed to:

1. Set elabBuildHaddocks = False at the point where the hash is
   initially computed.
2. Verify that elabBuildHaddocks = True will not lead to unexpected
   results.

The latter has been implemented.

The elabBuildHaddocks option is only consulted in
`hasValidHaddockTargets`, at which point documentation building the
executable component is disabled because elabHaddockExecutables is
False.

In the added test we ensure this by checking that we didn't build
documentation for the executable which is built because of
build-tool-depends.

Fixes #6006 #8313

* Fix Semigroup target instance

When two target names are the same, `mappend`ing them should not
error but just pick the first name.

* Add `desugarBuildToolSimple`

* Reimplement cabal check

* Reorder test output

* Fix autogen modules tests .cabal files

* Add a number of tests

* Add test for #7423

i.e. Do not warn on -O2 if under off-by-default package configuration
flag conditional.

* Add a regression for:

    * Add another -WErrr test
        This is to make sure we do *not* report it if it is under
        a user, off-by-default flag.
    * Add test for non manual user flags.
    * Add “absolute path in extra-lib-dirs” test
    * Add if/else test
    * Add “dircheck on abspath” check
    * Add Package version internal test
    * Add PackageVersionsStraddle test

* Add changelog for #8427

* Integrate various reviews

* Integrate Artem’s review

(review) Clarify `combineNames` documentation

By explaining the way it operates (working if the two names are equal
or one is empty) and renaming the function from `combineName` to
`combineNames`.

(review) Use guards instead of if/then/else

(review) Match inside argument list

(review) Replace “white” with “allow”

(review) Fix typo in comment

(review) Fix typo in Check module documentation

(review) Harmonise indentation for `data` decls

First field goes in a new line than the data constructor, so we
have more space.

(review) Rename `Prim` module to `Types`

(review) Add checkPackageFilesGPD

`checkPackageFiles` — which works on PD — was used to perform IO. We
introduce a function that does the same thing but works on GPD (which
is more principled).

`checkPackageFiles` cannot just be removed, since it is part of the
interface of Distribution.PackageDescription.Check. Deprecation can
be planned once “new check” is up and running.

* Integrate Andreas’ review

(review) Add named section to missing upper bound check

“miss upper bound” checks will now list target type and name (“On
executable 'myexe', these packages miss upper bounds”) for easier
fixing by the user.

(review) remove `cabal gen-bounds` suggestion

Reasonable as `cabal gen-bounds` is stricter than `cabal check`, see
https://github.com/haskell/cabal/pull/8427#issuecomment-1446712486


Once `gen-bounds` behaves in line with `check` we can readd the
suggestion.

(review) Do not warn on shared bounds

When a target which depends on an internal library shares some
dependencies with the latter, do not warn on upper bounds.

An example is clearer

    library
     build-depends: text < 5
    ⁝
     build-depends: myPackage,        ← no warning, internal
                    text,             ← no warning, shared bound
                    monadacme         ← warning!

* Integrate Artem’s review /II

(review) Split Check.hs

Check.hs has been split in multiple file, each une sub 1000 lines:

Check              857 lines
Check.Common       147 lines
Check.Conditional  204 lines
Check.Monad        352 lines
Check.Paths        387 lines
Check.Target       765 lines
Check.Warning      865 lines

Migration guide:
- Check              GPD/PD checks plus work-tree checks.
- Check.Common       common types and functions that are
                     *not* part of monadic checking setup.
- Check.Conditional  checks on CondTree and related matter
                     (variables, duplicate modules).
- Check.Monad        Backbone of the checks, monadic inter-
                     face and related functions.
- Check.Paths        Checks on files, directories, globs.
- Check.Target       Checks on realised targets (libraries,
                     executables, benchmarks, testsuites).
- Check.Warning      Datatypes and strings for warnings
                     and severities.

(review) remove useless section header

(review) Fix typo

(review) Add warnings documentation (list)

For each warning, we document constructor/brief description
in the manual.  This might not be much useful as not but it
will come handy when introducing `--ignore=WARN` and similar
flags.

* (review Andreas) Clarify CheckExplanation comment

Whoever modifies `CheckExplanation` data constructors needs to be
aware that the documentation in  doc/cabal-commands.rst  has to be
updated too.

* Move internal Check modules to `other-modules`

No need to expose Distribution.PackageDescription.Check.*
to the world. API for checking, for cabal-install and other
tools, should be in Distribution.PackageDescription.Check.

* Make fourmolu happy

Cabal codebase has now a formatter/style standard (see #8950).

“Ravioli ravioli, give me the formuoli”

* Do not check for OptO in scripts

See #8963 for reason and clarification requests.

* Remove useless PackageId parameter

It is now in the Reader part of CheckM monad.

* Do not check PVP on internal targets

Internal: testsuite, benchmark.
See #8361.

* Make hlint happy

* Fix #9122

When checking internal version ranges, we need to make sure we
are not mistaking a libraries with the same name but from different
packages. See #9132.

* Fix grammar

neither…nor, completing what done in #9162

* Integrate Brandon’s review: grammar

* Remove unnecessary `-fvia-C` check

Brandon’s review/II.

---------

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

* Add a 'cabal path' command.

* Formatting fix.

* Another formatting fix.

* Categorise "cabal path" as global command.

* Allow individual paths to be printed.

* Less duplication.

* Add config-file to "cabal path".

* Use sum type instead of strings.

* cabal path: support --installdir.

* Add documentation.

* Better text.

* Formatting.

* Add some tests.

* Improve tests.

* Add changelog entry.

* Mention "cabal path" in directory documentation.

---------

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

* Use PackageInfo for cabal-install version number

* Use Paths_cabal_install instead

* Adjust documentation

---------

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

Fixes #9197

Co-authored-by: Javier Sagredo <jasataco@gmail.com>
Co-authored-by: Andrea Bedini <andrea.bedini@tweag.io>
Co-authored-by: Andrea Bedini <andrea@andreabedini.com>

Fix #2349 and #7825

* Use ProjectFlags to define CleanCmd

The nearly identical PR for #7439 was used as a guide for this PR.
The point of this PR is to reduce the duplication of project flag
handling.

Co-authored-by: Jean-Paul Calderone <exarkun@twistedmatrix.com>

* remove duplicate support for project-dir

* switch use of NamedFieldPuns to RecordWildCards

---------

Co-authored-by: Jean-Paul Calderone <exarkun@twistedmatrix.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

As part of improving DX for new contributors, I have added
or revised comments to the Cabal/Distribution.Simple.Flag file,
giving it 100% comment coverage, as well as pointing out
its isomorphism to Maybe, and adding markdown for internal links.

Cabal/Distribution.Utils.IOData received a comment on withIOData,
and had the comment on IODataMode expanded. It is still
missing a comment on KnownIODataMode.

Cabal/Distribution.Lex received a comment on its sole function,
so its writer won't get annoyed by newbies unfamiliar with
its lexing pattern in the future.

Recent comments on Cabal/Distribution.Simple.defaultMainHelper
and cabal-install/Distribution.Client.Main.main were amended
for clarity, and to note the "--" behavior on
Distribution.Client.Main.main's expandResponse.