This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 25 Jun, 2016 5 commits
  2. 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
  3. 21 Jun, 2016 2 commits
  4. 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
  5. 07 Jun, 2016 3 commits
  6. 06 Jun, 2016 1 commit
  7. 05 Jun, 2016 2 commits
  8. 04 Jun, 2016 2 commits
  9. 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
  10. 02 Jun, 2016 1 commit
  11. 31 May, 2016 1 commit
  12. 30 May, 2016 5 commits
    • Duncan Coutts's avatar
      Improve internal error checking to avoid issues like #3428 · 3d1f5ba9
      Duncan Coutts authored
      Check that we do get the registration info we expect in a couple places,
      and add detail to the error message originally reported in #3428.
      
      Also build the integration tests with assertions on, which might have
      caught this error earlier (via the invariant for the install plan).
      3d1f5ba9
    • Duncan Coutts's avatar
      Fix issue 3428, update the install plan with the right info · ba919898
      Duncan Coutts authored
      When building packages we update the install plan with the completed
      packages and for libraries we include the InstalledPackageInfo. We
      now support packages that register multiple libraries but only one of
      them is the representative public library, and only that one is stashed
      in the install plan. Out of the list of library registraions we select
      the primary one by looking for the one with the expected unit it. As
      part of collecting the registration info we do some processing (to
      account for older Cabal and ghc versions) and the mistake was that
      while did that post-processing ok and registered the right libraries
      we ended up returing the un-processed registraion info and so then
      failed to find the primary lib, and thus failed to stash any library
      info in the install plan, causing internal errors later on.
      
      So this patch fixes it to return the same post-processed registration
      info as actually gets registered. Subsequent patches improve the
      internal error checking for this issue.
      ba919898
    • Mikhail Glushenkov's avatar
      Merge pull request #3468 from accraze/system-docs · 48a1de52
      Mikhail Glushenkov authored
      Documentation for known os and arch aliases
      48a1de52
    • Oleg Grenrus's avatar
      Time different blocks of travis script · e581f755
      Oleg Grenrus authored
      e581f755
    • accraze's avatar
      Adding comments for known os and arch aliases · 11650b26
      accraze authored
      11650b26
  13. 29 May, 2016 1 commit
  14. 28 May, 2016 8 commits