This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 02 Jul, 2016 2 commits
  2. 01 Jul, 2016 1 commit
  3. 30 Jun, 2016 2 commits
  4. 27 Jun, 2016 6 commits
  5. 26 Jun, 2016 4 commits
  6. 25 Jun, 2016 5 commits
  7. 22 Jun, 2016 1 commit
    • byorgey's avatar
      init: Only add exposed-modules which are in an hs-source-dir · fb514630
      byorgey authored and Mikhail Glushenkov's avatar Mikhail Glushenkov committed
      Only those modules found in a directory in hs-source-dirs will be added
      to exposed-modules.  If a directory 'src' is found it will be used as
      hs-source-dirs (note in this case any .hs files in the root directory
      will NOT be added to exposed-modules).  If any directories are specified
      on the command line with --source-dir, they will be used.  If no
      directories are specified on the command line and there is no directory
      named src, the root directory will be used.
      
      Fixes #3484.
      fb514630
  8. 21 Jun, 2016 2 commits
  9. 20 Jun, 2016 2 commits
    • Duncan Coutts's avatar
      Exit with non-0 code when build fails · ba2065f4
      Duncan Coutts authored
      Fixes issue #3495
      
      This also adds a stub where we can add more detailed failure reporting,
      but this starts with nothing more than the exit code.
      
      Unlike the existing "cabal install" failure reporting, we don't need or
      want "build" failure reporting to be quite so noisy in common cases like
      the one local package failing to build, since ghc reports its own errors
      and there's enough context to see what's going on.
      ba2065f4
    • Duncan Coutts's avatar
      Change install lock to just a registration lock · 1acc00f8
      Duncan Coutts authored
      Allowing parallel installation of files, just serialising the actual
      registration. Also previously only store package installs were
      serialised but we also need to serialise registration of packages in the
      local inplace package db.
      1acc00f8
  10. 07 Jun, 2016 3 commits
  11. 06 Jun, 2016 1 commit
  12. 05 Jun, 2016 2 commits
  13. 04 Jun, 2016 2 commits
  14. 03 Jun, 2016 6 commits
    • Duncan Coutts's avatar
      Remove the now-redundant build JobLimit · 05079dd0
      Duncan Coutts authored
      The parallel JobControl now has a built-in maximum job limit, so the
      separate build JobLimit is unnecessary. The separate fetch JobLimit
      is still useful.
      05079dd0
    • Duncan Coutts's avatar
      Add a test of the --keep-going feature · e1e6e123
      Duncan Coutts authored
      This actually only tests the new-build side of things, but the code in
      both cases is essentially identical. It also only tests the serial
      JobControl not the parallel JobControl. It may be sensible to have a
      specific unit test for the two JobControl implementations.
      e1e6e123
    • Duncan Coutts's avatar
      Add some tests for the JobControl impls · e2495eb6
      Duncan Coutts authored
      Including cancelling.
      e2495eb6
    • Duncan Coutts's avatar
      Add a --keep-going flag and plumb it through · 53e7da37
      Duncan Coutts authored
      For both install and new-build.
      53e7da37
    • Duncan Coutts's avatar
      executeInstallPlan: mode to stop as soon as possible after failure · bf72b4f0
      Duncan Coutts authored
      Add a keepGoing :: Bool arg to control whether to keep going after a
      build failure or whether to try and stop as soon as possible.
      
      This makes use of the new JobControl interface to try cancelling
      outstanding jobs and also for checking if there are jobs in progress.
      
      For now the call sites are hard coded to use keepGoing = False.
      bf72b4f0
    • Duncan Coutts's avatar
      Extend the JobControl interface with cancelJobs · 9f3dd88c
      Duncan Coutts authored
      The motivation here is to support an install mode where we stop as soon
      as possible after one package fails, rather than going on as far as
      possible with other packages.
      
      To properly support this we need to be able to cancel jobs that have
      been submitted but that have not yet been started. This is easy for the
      serial JobControl but requires re-implementing the paralle JobControl.
      
      In the previous impl we simply fork a thread immediately for each job
      (and use a JobLimit externally to limit parallelim). The problem with
      that is that all submitted jobs are actually executing, so there's no
      way to cancel jobs that have not started yet (there are none). Combined
      with the executeInstallPlan behaviour of exposing the maximum possible
      paralleism this means that there can be a lot of jobs in progress
      (though most waiting on the JobLimit), and none of them can be sanely
      cancelled.
      
      So in this impl we have a built-in maximum parallelism, so we're
      executing at most that many jobs at once, while all others are waiting
      to be executed. The ones that are waiting can be cancelled.
      
      Because it's unspecified how many jobs can be cancelled, users can no
      longer rely on counting the number of outstanding jobs so we add a new
      method to check if there are any jobs remaining.
      
      Subsequent patches will add tests and make use of these new features to
      stop the install process as soon as possible after a failure, with a
      new --keep-going flag to get the existing behaviour.
      9f3dd88c
  15. 02 Jun, 2016 1 commit