This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 27 Aug, 2014 2 commits
  2. 22 Aug, 2014 1 commit
  3. 13 Aug, 2014 1 commit
  4. 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
  5. 02 Aug, 2014 1 commit
  6. 29 Jul, 2014 3 commits
  7. 27 Jul, 2014 2 commits
  8. 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
  9. 25 Jun, 2014 2 commits
  10. 24 Jun, 2014 7 commits
  11. 28 May, 2014 1 commit
  12. 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
  13. 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
  14. 11 May, 2014 1 commit
  15. 14 Apr, 2014 1 commit
  16. 10 Apr, 2014 1 commit
  17. 21 Mar, 2014 1 commit
  18. 19 Dec, 2013 2 commits
  19. 17 Dec, 2013 2 commits
  20. 06 Dec, 2013 2 commits
  21. 05 Dec, 2013 3 commits
    • Mikhail Glushenkov's avatar
      Whitespace, formatting. · 270e771d
      Mikhail Glushenkov authored
      270e771d
    • Mikhail Glushenkov's avatar
    • Mikhail Glushenkov's avatar
      Solver support for '--allow-newer'. · d5ea0dfc
      Mikhail Glushenkov authored
      Implemented by going through all packages in the 'depResolverSourcePkgIndex' and
      applying 'relaxUpperBound' to the dependencies listed in 'build-depends'.
      
      Known issue:
      'build-depends: a < 3 && >= 2; if (someFlag): build-depends: a >= 5 && < 6'
      gets converted to
      'build-depends: >= 2; if (someFlag): build-depends: a >= 5'
      (4 is now allowed where it previously wasn't).
      
      Example:
      
          $ cabal install --dry-run ./tst
          Resolving dependencies...
          In order, the following would be installed (use -v for more details):
          array-0.3.0.3 (latest: 0.5.0.0)
          tst-0.1.0.0 (latest: 0.1.1)
      
          $ cabal install --dry-run --allow-newer=array ./tst
          Resolving dependencies...
          In order, the following would be installed (use -v for more details):
          tst-0.1.0.0 (latest: 0.1.1)
      d5ea0dfc
  22. 04 Dec, 2013 1 commit
    • Mikhail Glushenkov's avatar
      Refactoring: change the return type of 'InstallPlan.ready'. · 2a75a448
      Mikhail Glushenkov authored
      Introduce a new type 'ReadyPackage' to represent packages that have all
      dependencies already installed. Make 'InstallPlan.ready' return '[ReadyPackage]'
      instead of '[(ConfiguredPackage, InstalledPackageInfo)]'.
      
      Also fix a bug where 'cabal configure' didn't pass '--dependency' options to
      'setup configure'.
      2a75a448