This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 25 Jun, 2016 1 commit
    • Duncan Coutts's avatar
      Change rebuildInstallPlan to return pre-improvement plan · 3d4d48ce
      Duncan Coutts authored
      It takes a solver plan, makes an "elaborated plan" with nix style hashes
      but still of mostly source package and then does an improvement phase to
      make a plan with pre-existing packages from the store.
      
      Previously it only returned the improved plan, but for some things it's
      also useful to see the original elaborated plan with the source
      packages. In partciular it will be useful for plan.json status output.
      It will also be needed for the freeze command to be able to get at the
      flag choices, since this info is not preserved in installed packages.
      3d4d48ce
  2. 06 Jun, 2016 1 commit
  3. 05 Jun, 2016 2 commits
  4. 04 Jun, 2016 2 commits
  5. 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
  6. 02 Jun, 2016 1 commit
  7. 31 May, 2016 1 commit
  8. 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
  9. 29 May, 2016 1 commit
  10. 28 May, 2016 10 commits
  11. 27 May, 2016 2 commits
    • Mikhail Glushenkov's avatar
      Merge pull request #3437 from dcoutts/issue-3394 · a8290305
      Mikhail Glushenkov authored
      Fix handling of default setup deps
      a8290305
    • Duncan Coutts's avatar
      Add integration tests for setup script handling · 02464abe
      Duncan Coutts authored
      Covers 3 of the 4 possible cases:
      1. explicit custom setup deps
      2. custom setup with implicit/default deps
      4. non-custom setup using the internal cabal lib version
      
      case 3 is a non-custom setup but where we're forced to use an external
      cabal lib version. This case is hard to test since it only happens when
      it's a newer (not older) Cabal lib version that the package requires,
      e.g. a .cabal file that specifies cabal-version: >= 2.0.
      
      Also, add a --with-ghc option to the integration test suite, which lets us
      more easily test with different ghc versions.
      
      Also, don't use parallel builds in any of the integration tests, as the
      self-exec method will not work, and some tests need to install deps for
      some ghc versions.
      02464abe
  12. 24 May, 2016 6 commits
  13. 23 May, 2016 1 commit
  14. 22 May, 2016 1 commit