Co-authored-by: maralorn <malte.brandy@maralorn.de>

Motivation
----------
Often times, the user facing `ghc` binary is
symlinked by other forces, such as the package manager,
tooling like ghcup etc. As such, the naming convention
(version suffix in particular) may not align with the
assumptions made in Cabal and it may find an incorrect ghc-pkg.

See:
  - https://github.com/haskell/cabal/issues/7390
  - ghc/ghc#18807
  - haskell/ghcup-hs#73

Solution
--------
Guessing the ghc-pkg path is already a hack and will be solved
more appropriately in the future, see
  - ghc/ghc!4214
  - ghc/ghc$2710
These patches will solve the issue for future GHC versions.

As such, this patch provides a workaround for
older, already existing GHC versions by first always
following the symbolic link of the ghc binary (if it is one)
and prefering its target directory as the guess lookup
location.

Rationale
---------
The canonicalized path of the ghc binary usually points to the
bin/ directory unpacked from a bindist, which is less likely to be
tampered with by distributions and tools. As such, prefering the
canoncialized path should get us more robust results.

Set -Wno-prepositive-qualified-module in Paths_*.hs

Fixes #7351

Expose cabal-install lib, remove dogfooding, expose cabal-install-solver as own lib, enable HPC coverage reporting. 

* Changes needed for GenValidate and release.py to
  accommmodate new solver dependency
* Bumps bootstrap plans to modern GHC versions
* Update `validate.sh` and `release.py` to accommodate new solver dep.
* Update `Makefile` targets

* Strips away dogfooding framework and zinza templates
* Splits out tests into targets by as a function of running time
* Delete TESTING.md as it no longer applies
* Bump cabal-install.cabal to its dev template settings (base >= 4.10,
Cabal 2.2)
* Remove Paths_cabal_install (blocks HPC generation)
* Add `long-tests` target to split out unit-tests and long-running
  DVCS tests.

* Add Setup.hs for `cabal-install-solver`
* Update `cabal.project` pkg path for `cabal-install-solver`

* Documented limitation of compiler flag

* Added changelog entry

* Removed changelog entry

* Removed empty promise

* Removed another promise

Co-authored-by: James Hobson <james.hobson@oriel.ox.ac.uk>

* GHC: Rename cLikeFiles -> cLikeSources

* changelog: Add entry for #7252

* Add name change convention for c-like objects

Co-authored-by: Emily Pillmore <emilypi@cohomolo.gy>

* Add language and extensions for 9.2
* Add changelog entry for extensions
* Add vim editor entry for 9.2 extensions

Co-authored-by: Ben Gamari <ben@smart-cactus.org>

Documented the interaction between Backpack and Template Haskell.

Workaround for failing test due to GHC #19397

Fix test --enable-coverage for multi-package projects

Include `cmm-sources` when linking shared objects

Mark "install --lib" as provisional

Ollie Charles authored 4 years ago and Ollie Charles committed 4 years ago

Currently, if you have multiple packages in a project and try and run
the test suite of a single package with --enable-coverage, hpc will fail
to run. The problem is that _all_ dependencies of the package are built
with `-fhpc`, but when we run `hpc markup`, we are only passing the
`.mix` directory of the package being tested. Because we built all
dependencies with `-fhpc` and we haven't excluded them from the report,
we need to supply their `.mix` directories too.

The above suggests one fix - compute the transitive closure of all
`.mix` directories. However, there is another solution - change from
using an exclude-list to using an include-list. This is the approach
used in this commit.

Explicitly enumerating all modules to _include_ in the report is simpler
to code, but is also more likely to be what the user is interested in.
Generally, when one generates a coverage report from a test-suite, they
want to understand the coverage of the unit being tested. Having
coverage information from dependencies is usually not relevant. This is
also the behavior from old-style Cabal builds, where there wasn't even
a notion of a Cabal project.

Fixes #5433.

And don't encourage its use as much as before. Adding packages to
build-depends is more often what the user wants.

This is based on / similar to https://github.com/haskell/cabal/pull/7219

We used import qualified M in Paths_*.hs, which might be disallowed in
GHC 8.10 when -Wprepositive-qualified-module is set.

--only-download flag

--dry-run
--only-dependencies
--only-configure
--only-download

Allow bytestring-0.11 + tree-diff-0.2

Bump Win32 upper bound

Actually propagate base16-bytestring 1.0 to all cabal files

Suggest command on spelling mistakes