This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 03 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Switch InstallPlan over to using IPID-indexed PackageIndex. · ff6c718b
      Edward Z. Yang authored
      While this doesn't let us get rid of Distribution.Client.PackageIndex,
      it does make InstallPlan more flexible, so we can have the same
      package name-package version in the install plan multiple times.
      We do this by synthesizing fake installed package IDs to act
      as placeholders prior to compilation.
      
      There is some shindig with 'FakeMap' in PackageIndex, check out
      the Note in that file for more details.
      
      This reverts commit a5a0f8e1959003ee702c04a23375a60d48f03f90, with
      a bugfix for linearizeInstallPlan.
      
      Fixes #2123
      ff6c718b
  2. 23 Sep, 2014 1 commit
  3. 18 Sep, 2014 1 commit
  4. 27 Aug, 2014 2 commits
  5. 22 Aug, 2014 1 commit
  6. 13 Aug, 2014 1 commit
  7. 04 Aug, 2014 3 commits
    • Edward Z. Yang's avatar
      Disable reinstalls with distinct package keys for now. · d3a696a3
      Edward Z. Yang authored
      
      
      Duncan requested that cabal-install not try to put multiple entries in the
      package database with duplicate package IDs (foo-0.1) until other tools (in
      particular GHC) are able to deal with situation in a better way.  We want to
      revert this commit soon, since with this turned on, we basically don't get any
      benefit from the package key refactoring (no deliverance from Cabal hell.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      d3a696a3
    • Edward Z. Yang's avatar
      Add $pkgkey template variable, and use it for install paths. · 1d33c8f5
      Edward Z. Yang authored
      
      
      At the moment, $pkgkey is not supported for build reports, although in
      principle we could add support for it, assuming that the configure step
      succeeds.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      1d33c8f5
    • Edward Z. Yang's avatar
      Implement package keys, distinguishing packages built with different deps/flags · 41610a0b
      Edward Z. Yang authored
      
      
      Previously, the GHC ecosystem assumed that for any package ID (foo-0.1), there
      would only be one instance of it in the installed packages database.  This
      posed problems for situations where you want a package compiled twice against
      different sets of dependencies: they could not both exist in the package
      database.
      
      Package keys are a hash of the package ID and package
      dependencies, which identify a package more uniquely than a package ID, but less
      uniquely than an installed package ID. Unlike installed package IDs, these can
      be computed immediately after dependency resolution, rather than after
      compilation.  Package keys require support from the compiler.  At the moment,
      only GHC 7.10 supports package keys (the reason is that old versions of GHC
      do a sannity check to see that the <pkg-name>-<pkg-version> stored in the
      package database matches with the -package-name embedded in an hi file; so
      the format is fixed.) We fallback to package keys == package IDs for old
      versions.
      
      Note: the ./Setup configure fallback script does not try particularly hard to
      pick consistent sets of dependencies.  If your package database is too difficult
      for it to resolve, manually provide installed package IDs or use cabal-install's
      dependency solver.
      
      Note: This patch *suspends* the reinstall check unless it would result in
      a different package, so cabal-install will now happily reinstall foo-0.1
      compiled against bar-0.2 if foo-0.1 already exists.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      41610a0b
  8. 02 Aug, 2014 1 commit
  9. 29 Jul, 2014 3 commits
  10. 27 Jul, 2014 2 commits
  11. 21 Jul, 2014 1 commit
    • Isamu Mogi's avatar
      Read installed package info file as UTF-8 · 44a261d4
      Isamu Mogi authored
      Currently installed package info file is written in UTF-8. So UTF-8
      should be used explicitly or it can cause "invalid byte sequence"
      error if system encoding is incompatible to UTF-8.
      44a261d4
  12. 25 Jun, 2014 2 commits
  13. 24 Jun, 2014 7 commits
  14. 28 May, 2014 1 commit
  15. 23 May, 2014 1 commit
    • Andres Löh's avatar
      Configurable strong/weak flags. · f950e8d7
      Andres Löh authored
      This adds a mechanism in the modular solver to store whether a flag
      is "strong" or "weak". A weak flag is deferred during solving, a strong
      flag is not.
      
      By default, flags are now weak unless they're manual. This is a change
      in behaviour, but I think it's probably the better default, because many
      automatic flags are used to figure out what's on the system rather than
      to impose hard constraints.
      
      There's a new flag --strong-flags that restores the old behaviour. I do
      not think such a global flag is particularly useful, but it may be
      of interest to compare build plans between the new and old behaviour.
      
      With these preparations, it's easy to make the distinction between
      strong and weak flags more sophisticated. We can either add more
      heuristics as to when flags should be treated as strong or weak, or we
      can add syntax to .cabal files that allows package authors to specify
      explicitly how they intend a flag to behave.
      
      This is related to various cabal-install issues, e.g. #1831, #1864,
      and #1877.
      
      (cherry picked from commit 3dcddea4)
      
      Conflicts:
      	cabal-install/Distribution/Client/Dependency.hs
      f950e8d7
  16. 19 May, 2014 1 commit
    • Andres Löh's avatar
      Configurable strong/weak flags. · 3dcddea4
      Andres Löh authored
      This adds a mechanism in the modular solver to store whether a flag
      is "strong" or "weak". A weak flag is deferred during solving, a strong
      flag is not.
      
      By default, flags are now weak unless they're manual. This is a change
      in behaviour, but I think it's probably the better default, because many
      automatic flags are used to figure out what's on the system rather than
      to impose hard constraints.
      
      There's a new flag --strong-flags that restores the old behaviour. I do
      not think such a global flag is particularly useful, but it may be
      of interest to compare build plans between the new and old behaviour.
      
      With these preparations, it's easy to make the distinction between
      strong and weak flags more sophisticated. We can either add more
      heuristics as to when flags should be treated as strong or weak, or we
      can add syntax to .cabal files that allows package authors to specify
      explicitly how they intend a flag to behave.
      
      This is related to various cabal-install issues, e.g. #1831, #1864,
      and #1877.
      3dcddea4
  17. 11 May, 2014 1 commit
  18. 14 Apr, 2014 1 commit
  19. 10 Apr, 2014 1 commit
  20. 21 Mar, 2014 1 commit
  21. 19 Dec, 2013 2 commits
  22. 17 Dec, 2013 2 commits
  23. 06 Dec, 2013 2 commits
  24. 05 Dec, 2013 1 commit