This project is mirrored from Pull mirroring updated .
  1. 21 Aug, 2016 11 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
    • 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
      * 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
      * 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 <>
    • Edward Z. Yang's avatar
      Undo new-build support for convenience libraries. · e6b6167d
      Edward Z. Yang authored
      The previous approach I took, though correct, was quite
      confusing.  If I refactor InstallPlan to operate on a
      per-component basis, then we'll automatically get support
      for convenience libraries, which will ultimately cleaner.
      (While we won't be able to get rid of support for whole
      package installs, it will be safe to assume packages
      using convenience libraries also support one-shot
      I didn't revert the support in cabal install; I'm not
      planning on componentizing it.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      One-component configure, fixes #2802. · a090a494
      Edward Z. Yang authored
      Described in:
      ./Setup configure now takes an argument to specify a specific
      component name that should solely be configured.
      Most of the gyrations in Configure are all about making it so that
      we can feed in internal dependencies via --dependency.
      I dropped the package name match sanity check to handle convenience
      library package name munging.  Consider an internal library named
      'q' in package 'p'.  When we install it to the package database,
      we munged the package name into 'z-p-z-q', so that it doesn't
      conflict with the actual package named 'q'.  Now consider when
      we feed it in with --dependency q=p-0.1-hash-q.  Previously,
      Cabal checked that the 'q' in --dependency matched the package
      name in the database... which it doesn't. So I dropped the check.
      I also had to make register/copy unconditionally install internal
      libraries; otherwise you can't refer to them from later builds.
      Also a miscellaneous refactor: convenience libraries are printed with a
      "header" stanza now (not really a stanza header).
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Merge pull request #3645 from grayjay/unknown-package-message · e08a1ea8
      Edward Z. Yang authored
      Avoid filtering the solver log before 'showMessages'.
    • Edward Z. Yang's avatar
      Merge pull request #3698 from ezyang/pr/respect-enable-test-flags · 12ca63dd
      Edward Z. Yang authored
      Fix #2755 by always respecting enable flags on configure.
    • Edward Z. Yang's avatar
      Merge pull request #3695 from ezyang/pr/ifndef-current-pkg-key · cbb771db
      Edward Z. Yang authored
      Fix #3041, ifndef all CURRENT_PACKAGE_KEY and related macros.
  2. 20 Aug, 2016 1 commit
  3. 18 Aug, 2016 2 commits
  4. 17 Aug, 2016 6 commits
  5. 16 Aug, 2016 1 commit
  6. 14 Aug, 2016 1 commit
  7. 13 Aug, 2016 1 commit
  8. 11 Aug, 2016 8 commits
  9. 10 Aug, 2016 7 commits
    • Federico Mastellone's avatar
      Merge pull request #3688 from haskell/issues-3687 · a89e5482
      Federico Mastellone authored
      AppVeyor fails installing GHC 7.10.3
    • Federico Mastellone's avatar
      AppVeyor fails installing GHC 7.10.3 · da051653
      Federico Mastellone authored
      This fixes #3687
      Swithed AppVeyor test to GHC 8.0.1 because 7.10.3 is broken ( and added the `-y` option and `refreshenv` after installing GHC as suggested by Chocolatey
    • 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.
    • 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
    • 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.
    • 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.
    • 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.
  10. 09 Aug, 2016 1 commit
  11. 08 Aug, 2016 1 commit