This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 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
  2. 05 Nov, 2012 1 commit
  3. 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
  4. 29 Jun, 2012 1 commit
  5. 28 Jun, 2012 1 commit
  6. 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
  7. 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
  8. 28 Mar, 2012 1 commit
  9. 19 Feb, 2012 1 commit
  10. 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
  11. 28 Oct, 2011 1 commit
  12. 27 Oct, 2011 1 commit
  13. 14 Jun, 2011 1 commit
  14. 14 Apr, 2011 1 commit
  15. 27 Mar, 2011 1 commit
  16. 04 Mar, 2011 2 commits
  17. 13 Feb, 2011 4 commits
  18. 11 May, 2010 1 commit
  19. 29 Dec, 2009 1 commit
  20. 22 Oct, 2009 1 commit
  21. 18 Oct, 2009 1 commit
  22. 31 May, 2009 2 commits
  23. 26 Jan, 2009 2 commits
  24. 25 Jan, 2009 1 commit