1. 21 May, 2021 3 commits
  2. 20 May, 2021 1 commit
  3. 18 May, 2021 2 commits
  4. 12 May, 2021 2 commits
    • Julian Ospald's avatar
      eabedbde
    • Julian Ospald's avatar
      Prefer canonicalized path when guessing tools from GHC path · f78d2aaa
      Julian Ospald authored
      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.
      f78d2aaa
  5. 04 May, 2021 4 commits
  6. 03 May, 2021 2 commits
  7. 02 May, 2021 3 commits
    • Emily Pillmore's avatar
      Update CI for cabal-install and cabal-install-solver · bf8dff54
      Emily Pillmore authored
      * 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
      bf8dff54
    • Emily Pillmore's avatar
      Get HPC working for cabal-install · a54f9d23
      Emily Pillmore authored
      * 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.
      a54f9d23
    • Emily Pillmore's avatar
      Move cabal-install-solver to its own toplevel directory · 54696c14
      Emily Pillmore authored
      * Add Setup.hs for `cabal-install-solver`
      * Update `cabal.project` pkg path for `cabal-install-solver`
      54696c14
  8. 26 Apr, 2021 1 commit
  9. 25 Apr, 2021 1 commit
  10. 20 Apr, 2021 3 commits
  11. 18 Apr, 2021 2 commits
  12. 17 Apr, 2021 2 commits
  13. 14 Apr, 2021 3 commits
  14. 13 Apr, 2021 1 commit
  15. 12 Apr, 2021 1 commit
  16. 10 Apr, 2021 1 commit
    • Ollie Charles's avatar
      Fix test --enable-coverage for multi-package projects · 9d16b3ec
      Ollie Charles authored and Ollie Charles's avatar Ollie Charles committed
      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.
      9d16b3ec
  17. 09 Apr, 2021 1 commit
  18. 08 Apr, 2021 1 commit
  19. 07 Apr, 2021 1 commit
  20. 06 Apr, 2021 1 commit
  21. 03 Apr, 2021 3 commits
  22. 02 Apr, 2021 1 commit