This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 19 Sep, 2016 1 commit
  2. 09 Sep, 2016 2 commits
  3. 06 Sep, 2016 2 commits
  4. 24 Aug, 2016 1 commit
  5. 21 Aug, 2016 4 commits
    • Edward Z. Yang's avatar
      Rewrite ElaboratedConfiguredPackage. · c41ead76
      Edward Z. Yang authored
      
      
      As requested by Duncan, the majority of fields that originally
      lived in ElaboratedPackage now are moved to ElaboratedConfiguredPackage
      under the prefix 'elab'.  Some code has gotten simpler as a result.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      c41ead76
    • Edward Z. Yang's avatar
      Be more careful about ComponentId versus UnitId. · bd7e2310
      Edward Z. Yang authored
      
      
      Two big ideas:
      
          * @--dependency@ takes a ComponentId, not UnitId.
            I used to think it should be a UnitId but it is
            now clear that you want to finger the indefinite
            unit id, which can be uniquely identified with
            a ComponentId
      
          * When hashing for an InstalledPackageId in
            new-build, we should produce a ComponentId,
            not a UnitId.
      
      While cleaning up the results, for any codepaths which we don't plan on
      implementing Backpack (Distribution.Client.Install, I'm looking at you),
      just coerce ComponentId into UnitIds as necessary.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      bd7e2310
    • Edward Z. Yang's avatar
    • 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
  6. 11 Aug, 2016 1 commit
  7. 10 Aug, 2016 5 commits
    • Duncan Coutts's avatar
      Rework reportBuildFailures to include build logs · 5fe5202b
      Duncan Coutts authored
      Reporting build logs is important as we otherwise have no real info for
      why deps failed to build. It does make the presentation more difficult
      however because build logs can be long and in principle there can be
      several, which means it can take up more than a single screen in a
      console. The first thing users notice is typically the last few
      messages, so in the case that we're presenting long build logs then its
      important to also include a short summary at the end.
      
      So our approach is this: for packages where we want to show a build log,
      we dump those first, in full, each with a header to indicate which
      package it is, log file name (for later reference), plus any extra
      detail we have from the phase of the failure or the exception. Then
      after all build logs we end with a short summary of the failure(s). For
      packages where we do not show a build log (e.g. local packages that dump
      live to the console) we only present a summary at the end, but we
      include a little more detail than for the packages that had a build log
      since this is the only thing we report for them. So we include details
      of the exception.
      5fe5202b
    • Duncan Coutts's avatar
      Remove PlanningFailed and add {Repl,Haddocks}Failed · bfdd9539
      Duncan Coutts authored
      The PlanningFailed case does not happen. The ReplFailed, HaddocksFailed
      cases were previously covered by BuildFailed but they're worth
      disinguishing.
      bfdd9539
    • Duncan Coutts's avatar
      Add the build log into the Build{Result,Failure} · 11ed1709
      Duncan Coutts authored
      In both cases it's optional and only added when the log file is used.
      This will be used later in reporting the build outcomes.
      11ed1709
    • Duncan Coutts's avatar
      Redefine the Build{Result,Failure,Outcome} types locally · 6421c3e2
      Duncan Coutts authored
      We're going to alter and extend the BuildResult and BuildFailure types
      for the new-build code, so we cannot share those types with the old
      install code.
      
      This patch doesn't change the structure, just redefines them locally and
      switches uses to record style so we can add new fields easily.
      6421c3e2
    • Duncan Coutts's avatar
      Rename BuildResult/BuildOutcome, BuildSuccess/BuildResult · 2a0505c7
      Duncan Coutts authored
      I think these names are now a bit more induitive / less confusing and a
      bit more consistent.
      
      We now have BuildOutcome(s) to mean either failure or a build result,
      and BuildResult to mean the result of a non-failing build.
      2a0505c7
  8. 03 Aug, 2016 2 commits
  9. 26 Jul, 2016 1 commit
    • Duncan Coutts's avatar
      Convert new-build to use the common BuildSuccess/Failure types · cdacc518
      Duncan Coutts authored
      As a result of the previous InstallPlan refactoring, we can now use the
      non-serialisable BuildFailure type from D.C.Types which uses
      SomeException, where previously we had to use a copy of that type that
      used String for the errors.
      
      So now there's no longer any need to have a separate set of types for
      BuildResult, BuildResults, BuildSuccess or BuildFailure. There was a
      minor difference in the structure of the BuildSuccess, where in the new
      build code we need to be able to produce the InstalledPackageInfo at a
      different point from the rest of the info in the BuildSuccess. This can
      be kept local to the ProjecBuilding module, but accounts for the
      somewhat larger number of changes in that module.
      cdacc518
  10. 25 Jul, 2016 2 commits
    • Duncan Coutts's avatar
      Convert new-build to use InstallPlan.execute · 97cff5c0
      Duncan Coutts authored
      Eliminate the local executeInstallPlan. The main change is that the new
      execute returns BuildResults instead of an upated InstallPlan. This has
      a few knock-on conseuqnces for the code that looks at the result of the
      build execution.
      
      Currently we don't actually do that much with the results in the
      new-build code path (though we should) so there's less disruption than
      one might imagine. The biggest change is in the integration tests which
      do inspect the execution result to check things worked or didn't work as
      expected.
      
      The equivalent change for the old build code path will be more
      disruptive since it does a lot of stuff with the execution results.
      97cff5c0
    • Duncan Coutts's avatar
      Replace linearizeInstallPlan utils by InstallPlan.executionOrder · af112a61
      Duncan Coutts authored
      Delete two different ugly versions of linearizeInstallPlan. Yay.
      af112a61
  11. 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
  12. 20 Jun, 2016 1 commit
    • 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
  13. 09 May, 2016 1 commit
    • Duncan Coutts's avatar
      Add better exception handling in new-build · 51da3c74
      Duncan Coutts authored
      When executing the install plan, the various failures are supposed to be
      caught and put into the residual install plan. This adds the main cases
      for that, including the configure and build cases. Download is still not
      covered.
      
      This is a step towards better reporting of what failed when there are
      failures in deps etc.
      51da3c74
  14. 26 Apr, 2016 1 commit
  15. 10 Apr, 2016 2 commits