This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 14 Jul, 2018 1 commit
  2. 09 Jan, 2018 1 commit
  3. 10 Mar, 2017 1 commit
  4. 07 Mar, 2017 3 commits
  5. 04 Sep, 2016 1 commit
  6. 21 Aug, 2016 1 commit
    • Edward Z. Yang's avatar
      Per-component new-build support (no Custom support yet). · d9bf6788
      Edward Z. Yang authored
      
      
      A bit of a megapatch.  Here's what's in it:
      
      * First, a few miscellaneous utility functions and reexports
        in Cabal.  I could have split these into a separate commit
        but I was too lazy to.
      
      * Distribution.Client.Install got refactored:
        instead of using PackageFixedDeps, it uses IsUnit
        instead.  This is because we weren't using ComponentDeps
        in a nontrivial way; we just need some graph structure
        and IsNode (with UnitId keys) fulfills that. I also removed the
        invariant checking and error reporting because it was
        being annoying (we check the invariants already in
        SolverInstallPlan).
      
      * Look at Distribution.Client.ProjectPlanning.Types.
        This contains the primary type change: ElaboratedConfiguredPackage
        is now EITHER a monolithic ElaboratedPackage, or a per-component
        ElaboratedComponent (it should get renamed but I didn't do that
        in this patch.)  These are what we're going to store in our
        plans: if a package we're building has a Setup script which supports
        per-component builds, we'll explode it into a component.  Otherwise
        we'll keep it as a package.  We'll see codepaths for both
        throughout.
      
      * OK, so the expansion happens in ProjectPlanning, mostly in
        'elaborateAndExpandSolverPackage'.  You should review the
        package hash computation code closely.  When we can separate
        components, we compute a hash for each INDEPENDENTLY.  This
        is good: we get more sharing.
      
      * We need to adjust the target resolution and pruning code
        in ProjectOrchestration and ProjectPlanning.  I did a dumb
        but easy idea: if a user mentions 'packagename' in a
        target name, I spray the PackageTarget on every
        possibly relevant IPID in buildTargets', and then pare
        it down later.
      
      * And of course there's code in ProjectBuilding to actual
        do a configure and then build.
      
      * We change the layout of build directories so that we can
        track each component separately.  While I was doing that,
        I also added compiler and platform information.
      
      Custom doesn't work yet because I need to give them their own
      separate component, and teach Cabal how to build them specially.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      d9bf6788
  7. 19 Jul, 2016 1 commit
  8. 03 Jun, 2016 1 commit
    • 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
  9. 27 May, 2016 1 commit
    • 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
  10. 15 May, 2016 2 commits
  11. 14 May, 2016 1 commit
    • Duncan Coutts's avatar
      Add new integration tests, initially covering build exceptions · 40846f06
      Duncan Coutts authored
      These integration tests, unlike the existing ones, don't call cabal as
      an external processes. Instead they use the cabal code directly. This
      makes it possible to conveniently test catching exceptions.
      
      Add a couple tests for exceptions in finding projects. There should be a
      lot more for the various phases of planning.
      
      Also add a couple tests for exceptions in the configure and build
      phases. These test the previous patch that improves the exception
      handling so that failures are added into the residual plan rather than
      just propagating immediately.
      40846f06