This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 30 Oct, 2014 1 commit
  2. 27 Aug, 2014 1 commit
  3. 02 Aug, 2014 1 commit
  4. 02 May, 2014 1 commit
  5. 19 Dec, 2013 2 commits
  6. 06 Dec, 2013 1 commit
  7. 05 Dec, 2013 4 commits
  8. 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
  9. 29 Oct, 2013 1 commit
  10. 25 Oct, 2013 1 commit
  11. 03 Mar, 2013 1 commit
  12. 01 Mar, 2013 1 commit
    • lukexi's avatar
      Return Maybe Platform as part of compiler configure, and place it in... · 7a0941c8
      lukexi authored
      Return Maybe Platform as part of compiler configure, and place it in LocalBuildInfo as hostPlatform.
      GHC infers the platform form ghc --info using new 'platformFromTriple' function. Other compilers return Nothing, which triggers fallback to old behavior of using buildPlatform. hostPlatform is then threaded through to initialPathTemplateEnv.
      7a0941c8
  13. 05 Nov, 2012 1 commit
  14. 29 Sep, 2012 2 commits
    • Duncan Coutts's avatar
      On install, update the .cabal file with the one from the index · 22d37722
      Duncan Coutts authored
      (patch manually merged into the cabal-1.16 branch)
      
      This allows us to make minor changes to packages after they have been
      released, without changing the package .tar.gz file. We already keep
      the .cabal file outsite the package in the index and use it for
      dependency planning. This already lets us do fixes such as making
      dependency constraints tighter. Currently we cannot make dep
      constraints more relaxed however, since the original .cabal file is
      the one used when we get to the actual configure step.
      
      So with this change, we now use the updated .cabal file for the
      configure and build too. So there's more fixes we can do post-release.
      In particlar, in combination with easier editing on hackage, this
      should help us address the problems around the PVP and open or closed
      version constraints. It should allow a system of conservative upper
      bounds, but allow editing them when new versions of deps are released
      and we find that they happen to work fine.
      22d37722
    • Duncan Coutts's avatar
      On install, update the .cabal file with the one from the index · b92cbb04
      Duncan Coutts authored
      This allows us to make minor changes to packages after they have been
      released, without changing the package .tar.gz file. We already keep
      the .cabal file outsite the package in the index and use it for
      dependency planning. This already lets us do fixes such as making
      dependency constraints tighter. Currently we cannot make dep
      constraints more relaxed however, since the original .cabal file is
      the one used when we get to the actual configure step.
      
      So with this change, we now use the updated .cabal file for the
      configure and build too. So there's more fixes we can do post-release.
      In particlar, in combination with easier editing on hackage, this
      should help us address the problems around the PVP and open or closed
      version constraints. It should allow a system of conservative upper
      bounds, but allow editing them when new versions of deps are released
      and we find that they happen to work fine.
      b92cbb04
  15. 29 Jun, 2012 1 commit
  16. 28 Jun, 2012 1 commit
  17. 24 Jun, 2012 1 commit
    • Duncan Coutts's avatar
      Parallelise the install command This is based on Mikhail Glushenkov's patches. · 43e5c8f1
      Duncan Coutts authored
      It adds a '-j N' (= 'number of jobs') option for the 'install' command, which
      can be used to specify the number of concurrent workers. If possible, at most
      N packages will be built concurrently.
      
      This version of the patch is less featureful than Mikhail's version but also
      rather simpler. The key difference compared to Mikhail's version is that this
      version is lacking the output serialisation and the ability to tag each output
      message with the task it came from. All output is interleaved. The next step
      will be to make parallel builds log to files rather than the console and only
      to display a summary on the console.
      
      In addition to not having to change the output functions, the code is a bit
      simpler by keep the structure of the code the same as before, rather than
      splitting it into a number of concurrent tasks with channels. Instead each
      task simply executes the same pattern of install actions and concurrency
      limits are enforced using semaphores.
      43e5c8f1
  18. 31 Mar, 2012 1 commit
    • Andres Löh's avatar
      choose default solver based on compiler version · 1a3ff039
      Andres Löh authored
      GHC-6.12 has base-3 depending on base-4. This is a situation the
      topdown solver is hacked to deal with, but the new modular solver
      currently doesn't support it. We therefore switch back to the
      topdown solver if a GHC version before 7 is detected, but switch
      to the modular solver by default in all other situations.
      1a3ff039
  19. 28 Mar, 2012 1 commit
  20. 19 Feb, 2012 1 commit
  21. 07 Feb, 2012 1 commit
    • ttuegel's avatar
      Handle test and benchmark dependencies through the resolver properly. · 2978ef8b
      ttuegel authored
      Previously, test and benchmark dependencies were handled by editing the
      package description to include or exclude those stanzas before running
      the dependency resolver. Test and benchmark dependencies could only be
      installed for source packages because no package description is available
      for named packages before dependency resolution.
      
      Now, test and benchmark stanzas are enabled or disabled through constraints
      passed to the dependency resolver. This way, we can install dependencies for
      the test suites of target packages without propagating '--enable-tests'
      through the entire dependency tree; i.e., tests and benchmarks, when enabled,
      are built only for target packages. Later, this will allow us to
      automatically run test suites and, e.g., install only upon their success.
      2978ef8b
  22. 28 Oct, 2011 1 commit
  23. 27 Oct, 2011 1 commit
  24. 14 Jun, 2011 1 commit
  25. 14 Apr, 2011 1 commit
  26. 27 Mar, 2011 1 commit
  27. 04 Mar, 2011 2 commits
  28. 13 Feb, 2011 4 commits
  29. 11 May, 2010 1 commit
  30. 29 Dec, 2009 1 commit
  31. 22 Oct, 2009 1 commit