This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 16 Dec, 2015 10 commits
    • Duncan Coutts's avatar
      Change regiserPackage to not require so much info · dee7e0a5
      Duncan Coutts authored
      Drop the now-unused PackageDescription and inplace :: Bool args. And
      instead of taking the whole LocalBuildInfo, just take the bits we need:
      the compiler and program db. The package db stack was already passed in
      separately. Also reorder args to follow standard conventions.
      dee7e0a5
    • Duncan Coutts's avatar
      Don't pass LocalBuildInfo to per-compiler registerPackage functions · b0b57da9
      Duncan Coutts authored
      Rather, pass the individual bits we need, which is the program db
      and in some cases the compiler. This is a step towards having the main
      registerPackage not take the LocalBuildInfo. That is useful in contexts
      like cabal-install where we do not have a full LocalBuildInfo, but we
      still want to be able to register packages in a compiler-agnostic way.
      b0b57da9
    • Duncan Coutts's avatar
      Move user logging out of registerPackage and into some callers · 27dd76a0
      Duncan Coutts authored
      The main reason is to stop using the pkg and inplace args so that we
      can drop them entirely. A side benefit is that we don't actually want
      to emit a setupMessage for inplace registering, since that's a rather
      uninteresting internal action. We only want it for the explicit
      register command. So only one caller gains a call to setupMessage.
      27dd76a0
    • Duncan Coutts's avatar
      Change the interface to the per-compiler registerPackage functions · f1ca9680
      Duncan Coutts authored
      Remove the now-unused PackageDescription and inplace :: Bool args.
      
      Not yet changed the compiler-independent registerPackage.
      f1ca9680
    • Duncan Coutts's avatar
      UHC: registerPackage stop using source pkg and inplace args · 17af6b98
      Duncan Coutts authored
      UHC's version of registerPackage is the only one that makes use of the
      PackageDescription and inplace :: Bool args, and it's quite wrong for
      doing so. Registering a package should depend on the content of the
      InstalledPackageInfo and the PackageDBStack to register into and the
      Compiler to register with. It should not depend on the original source
      PackageDescription, and should not need a separate inplace arg. The
      location is determined by the PackageDBStack. UHC was not following
      this pattern and thereby forcing the general compiler independent
      registerPackage to take annoying and unnecessary arguments.
      
      With this patch, the register location is determined by the
      PackageDBStack. The source package id also comes from the
      InstalledPackageInfo rather than the source PackageDescription.
      
      This patch does not yet change the registerPackage type.
      17af6b98
    • Duncan Coutts's avatar
      UHC: factor out getGlobalPackageDir function · 0501e50a
      Duncan Coutts authored
      It's used three times already. This isn't important on it's own, but
      simplifies subsequent changes, when we add yet another use of it.
      0501e50a
    • Duncan Coutts's avatar
      Add and export a showProfDetailLevel utlity · 3004316d
      Duncan Coutts authored
      To be used in cabal-install. Also use it in one place in Cabal.
      3004316d
    • Duncan Coutts's avatar
      Export a few more BuildTarget utils · 7d01c2e6
      Duncan Coutts authored
      7d01c2e6
    • Duncan Coutts's avatar
      Add more standard derived instances, Eq, Generic and Binary · 89fd3e09
      Duncan Coutts authored
      Most types have these already. This just adds a few more.
      89fd3e09
    • Herbert Valerio Riedel's avatar
      Relax upper bound to allow upcoming binary-0.8 · 35f50ba6
      Herbert Valerio Riedel authored
      This is needed in order to be able to update GHC HEAD to
      use binary-0.8 as planned for GHC 8.0
      
      /cc @kolmodin
      35f50ba6
  2. 14 Dec, 2015 1 commit
  3. 13 Dec, 2015 4 commits
  4. 09 Dec, 2015 1 commit
  5. 07 Dec, 2015 2 commits
  6. 06 Dec, 2015 1 commit
  7. 01 Dec, 2015 4 commits
  8. 27 Nov, 2015 4 commits
  9. 26 Nov, 2015 6 commits
  10. 25 Nov, 2015 2 commits
    • Danny Navarro's avatar
      Add solver tests for language extensions and flavours · 1f40772a
      Danny Navarro authored
      This also includes modifications to the solver testing DSL and the
      testing functions.
      
      This is necessary for merging PR #2732.
      1f40772a
    • Andres Löh's avatar
      Track language extensions and language flavours in the solver. · fd5e0c65
      Andres Löh authored
      Every package now "depends" on all language extensions
      (default-extensions and other-extensions) and language flavours
      (default-language and other-languages) it declares in its cabal file.
      
      During solving, we verify that the compiler we use actually
      supports selected extensions and languages. This has to be done
      during solving, because flag choices can influence the declared
      extensions and languages being used.
      
      There currently is no equivalent check performed on the generated
      install plans. In general, cabal-install performs a sanity check
      on the solver output, checking that the solver e.g. indeed includes
      all the declared dependencies of a package. There is no such
      double-checking for language extensions. This is not really
      problematic, as all that this change does is to make the solver
      more conservative rather than less. However, having a sanity check
      available might ultimately be nice to have.
      fd5e0c65
  11. 24 Nov, 2015 2 commits
  12. 23 Nov, 2015 2 commits
  13. 21 Nov, 2015 1 commit