1. Working directory is not contaminated with results of the testsuite.
   Tests can be written in a more liberal way (creating/writing files
   etc).
2. The tests are more hermetic.. for example it was basically impossible
   to write a test which run outside of a project context.
3. The overall path lengths will be much shorter, which has been a
   consistent issue on windows. We can remove hacks like
   `withShorterPathForNewBuildStore`.

Fixes #9711

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

Hannes Siebenhandl authored 1 year ago and Mikolaj Konarski committed 1 year ago

This reverts commit 3f4c81fd.

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.

* 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>

Matthew Pickering authored 2 years ago and Ben Gamari committed 1 year ago

* The top-level user interface to enable the use of the semaphore is the
  `--semaphore` flag. If you pass `-j4 --semaphore` then cabal will
  create a semaphore with 4 slots which is passed to ghc using the
  `-jsem` option so that all GHC processes coordinate to use 4
  capabilities.

  - The semaphore logic is provided by a new package `semaphore-compat`
    which provides a cross-platform abstraction for semaphores.

* The low level `./Setup.hs build` interface accepts the `--semaphore
  <SEMAPHORE>` option, which can be used to directly pass the semaphore
  you require to the Setup script.

Also adds ellipsis to lines in *.out files.

Matthew Pickering authored 2 years ago and Francesco Gazzetta committed 1 year ago

There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.

1. When a user writes "cabal repl <target>" then if the user is using a
   compiler > ghc-9.4.* then we will attempt to start a multi-session
   which loads the selected targets into one multi-package session of
   GHC.
1a. The closure property states that in order to load components `p` and `q` into
    the same session that if `p` depends on `z` and `z` depends on `q`
    then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
    `z` exists then it is already made into an inplace package by
    cabal). Therefore cabal has already engineered that there is source
    code locally available for all packages which we will want to load
    into a session.

2. The solver is unmodified, the solver is given the repl targets and
   creates a build plan as before. After the solver is completed then in
   `setRootTargets` and `pruneInstallPlan` we modify the install plan to
   enforce the closure property and mark which dependencies need to be
   promised.

   * Mark the current components as `BuildInPlaceOnly InMemory`, which
     indicates to the compiler that it is to be built in a GHC
     multi-session.
   * Augment the component repl targets to indicate that components
     required by the closure property (in addition to normal targets)
     will be loaded into the repl.
   * Modify the dependency edges in `compLibDependencies` to indicate
     which dependencies are the promised ones (which is precisely
     components which are `BuildInPlaceOnly InMemory` build styles).
     This is the field which is eventually used to populate the
     `--dependency` argument to `./Setup configure`.

Fixes #8491

* Use shorter hash for script-builds directories

Using a Base64 hash and truncating it to 26 characters, saves 38 chars,
which helps avoid long paths issues on Windows, while still providing
130 bits of hash in order to avoid collisions.

Bug #8841

* Use the script cache dir as the dist dir

Putting script build products under dist-newstyle within the cache
directory is unnecessary because we already control the cache directory
and can ensure there are no conflicts.

* Use the actual script name in the executable name

Previously, the script name was sanitized in final executable name,
because the executable name had to match the component name, which only
allowed for a limited character set. Now we can use the actual script
name in the executable name. This only lets us shorten the component
name without losing clarity.

* Add changelog entry

* Reenable script tests for Windows/ghc-9.4.*

Partially revert 78cbeba1.

* do not print "up to date" unless running build

* Update cabal-tests

* Add changelog

* Remove accidentally added test generated files

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

We've seen some instability in the test, compare

  https://github.com/haskell/cabal/issues/8416

This adds timestamped output to make it easier to
see what goes wrong in case the test fails again.

This makes the `finally` apply to the last `do` block as intended.
No real effect on the test, though.

* Turn off T3827 for new GHCs due to heisenbugs not caused by cabal

* Disable the test totally on Linux until we stop taking GHC from GHA

See https://github.com/haskell/cabal/issues/8032#issuecomment-1204113187

* It failed on OSX now, so let's disable it everywhere except on Windows

Who would have thought.

+ Update file-format-changelog.rst

The "up and running" file was written before the signal handler
was installed, so it was possible for the test to kill the
subprocess before, leading to a missed "exiting" line in the
output.

I hope this fixes the sporadic failures we're seeing (#8080).

Failures are tracked in issues
  https://github.com/haskell/cabal/issues/7610
  https://github.com/haskell/cabal/issues/7987
  https://github.com/haskell/cabal/issues/7989
  https://github.com/haskell/cabal/issues/8028
  https://github.com/haskell/cabal/issues/8032