This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 12 Oct, 2016 1 commit
    • Duncan Coutts's avatar
      Reduce path lengths for temp package src and build dirs · 8dc39db7
      Duncan Coutts authored
      This is for paths under $dist/tmp/ where we unpack package source
      tarballs and build them. This is for packages destined for the store.
      The names of these tmp dirs don't matter since they're guaranteed to be
      unique, so we only need short identifiers. So stop using full package
      names, and put the build artifacts in their own dir, rather than using a
      dist dir under the src dir.
      8dc39db7
  2. 02 Oct, 2016 1 commit
  3. 29 Sep, 2016 4 commits
  4. 28 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `Version` type opaque (#3905) · bb2026c4
      Herbert Valerio Riedel authored
      Similiar to dabd9d98 which made
      `PackageName` opaque, this makes `Distribution.Version.Version` opaque.
      
      The most common version numbers occuring on Hackage are 3- and
      4-part versions. This results in significant Heap overhead due to
      `Data.Version`'s inefficient internal representation.
      
      So like the `PackageName` commit, this commit is a preparatory commit to
      pave the way for replacing `Version`'s internal representation by a
      representation with a memory footprint which can be an order of
      magnitude smaller.
      
      Finally, this also adds a new functor-like convenience function
      
          alterVersion :: ([Int] -> [Int]) -> Version -> Version
      
      for modifying the version number components.
      bb2026c4
  5. 27 Sep, 2016 1 commit
    • Arian van Putten's avatar
      Make interactive setup delegate CTRL+C · 005f6dfa
      Arian van Putten authored
      Fixes #3899
      
      When cabal new-repl spawns ghci, it spawns this as a subprocess.
      In UNIX like systems, if a CTRL+C is sent to this child process
      it also bubbles up to the parent process, causing it to terminate.
      Also see https://hackage.haskell.org/package/process-1.4.2.0/docs/System-Process.html#g:4.
      
      However, this is not what we want for interactive subprocesses.
      Interactive processes usually define their own handlers for CTRL+C,
      for example GHCi uses CTRL+C to reset the input buffer. So instead
      of terminating on CTRL+C we want to delegate CTRL+C to GHCi
      and let it do its thing.
      
      Luckily, we can enable CTRL+C delegation such that the parent
      process ignores the CTRL+C and instead delegates it to the
      child process.
      005f6dfa
  6. 24 Sep, 2016 4 commits
    • Duncan Coutts's avatar
      Refactor implementation of InstallPlan.installed · d5288df0
      Duncan Coutts authored
      All the use sites (currently only two but soon to be three) use
      InstallPlan.installed to do a bulk change of states, differing only in
      the filter condition. So it simplifies things and shares more code if
      we make the main one be the bulk version. The InstallPlan.remove already
      works similarly.
      d5288df0
    • Duncan Coutts's avatar
      Distinguish PreExisting vs Installed in BuildStatus · 81691044
      Duncan Coutts authored
      Not a big deal, but should be useful later for more precise status
      reporting. For now just means the rebuild reasons can be more precise.
      81691044
    • Duncan Coutts's avatar
      Start using new InstallPlan.Installed state · 0de4177c
      Duncan Coutts authored
      Change improvement and --dry-run phases to use Installed state rather
      than the PreExisting state. This means that PreExisting is now only used
      for installed packages from the global db, and never for installed
      packages from the store.
      0de4177c
    • Duncan Coutts's avatar
      Add an Installed state to InstallPlan packages · 435725ef
      Duncan Coutts authored
      This patch just adds the state without yet using it. That'll follow in
      subsequent patches.
      
      So why add an Installed state? Didn't we just remove the Installed,
      Processing and Failed states? Those states were used when we followed
      the approach of updating the InstallPlan as a build progressed (whereas
      we now do traversals without altering the InstallPlan).
      
      The idea of adding an Installed state now is that we can more usefully
      represent the state of the plan when we "improve" the plan with packages
      from the store or when we update the plan having checked if inplace
      packages are up to date. Currently in these two places we replace
      Configured source packages with PreExisting packages. There's a couple
      problems with this. Firstly the PreExisting state only contains an
      InstalledPackageInfo which means we loose information compared to all
      the detail in the Configured source package. This is relevant for things
      like plan.json output or other features that want to know the status of
      a project. Secondly we have to fake things for executables since they
      are not properly represented by InstalledPackageInfo.
      435725ef
  7. 20 Sep, 2016 1 commit
  8. 19 Sep, 2016 5 commits
    • Duncan Coutts's avatar
      Refactor implementation of InstallPlan.installed · 66ed37a2
      Duncan Coutts authored
      All the use sites (currently only two but soon to be three) use
      InstallPlan.installed to do a bulk change of states, differing only in
      the filter condition. So it simplifies things and shares more code if
      we make the main one be the bulk version. The InstallPlan.remove already
      works similarly.
      66ed37a2
    • Edward Z. Yang's avatar
      Print that we are building all due to Custom setup. · 512648fd
      Edward Z. Yang authored
      
      
      Previously the output was:
      
          Building profunctors-5.2 lib...
          Building semigroupoids-5.1...
      
      Now it is:
      
          Building profunctors-5.2 (lib)...
          Building semigroupoids-5.1 (all, due to Custom setup)...
      
      Fixes #3808.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      512648fd
    • Duncan Coutts's avatar
      Distinguish PreExisting vs Installed in BuildStatus · f3fc6504
      Duncan Coutts authored
      Not a big deal, but should be useful later for more precise status
      reporting. For now just means the rebuild reasons can be more precise.
      f3fc6504
    • Duncan Coutts's avatar
      Start using new InstallPlan.Installed state · 8f870aa0
      Duncan Coutts authored
      Change improvement and --dry-run phases to use Installed state rather
      than the PreExisting state. This means that PreExisting is now only used
      for installed packages from the global db, and never for installed
      packages from the store.
      8f870aa0
    • Duncan Coutts's avatar
      Add an Installed state to InstallPlan packages · 492db5b5
      Duncan Coutts authored
      This patch just adds the state without yet using it. That'll follow in
      subsequent patches.
      
      So why add an Installed state? Didn't we just remove the Installed,
      Processing and Failed states? Those states were used when we followed
      the approach of updating the InstallPlan as a build progressed (whereas
      we now do traversals without altering the InstallPlan).
      
      The idea of adding an Installed state now is that we can more usefully
      represent the state of the plan when we "improve" the plan with packages
      from the store or when we update the plan having checked if inplace
      packages are up to date. Currently in these two places we replace
      Configured source packages with PreExisting packages. There's a couple
      problems with this. Firstly the PreExisting state only contains an
      InstalledPackageInfo which means we loose information compared to all
      the detail in the Configured source package. This is relevant for things
      like plan.json output or other features that want to know the status of
      a project. Secondly we have to fake things for executables since they
      are not properly represented by InstalledPackageInfo.
      492db5b5
  9. 09 Sep, 2016 1 commit
  10. 06 Sep, 2016 1 commit
  11. 24 Aug, 2016 1 commit
  12. 23 Aug, 2016 1 commit
  13. 21 Aug, 2016 6 commits
    • Edward Z. Yang's avatar
    • 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
    • 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
      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
    • 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
      configure.)
      
      I didn't revert the support in cabal install; I'm not
      planning on componentizing it.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      e6b6167d
  14. 11 Aug, 2016 1 commit
  15. 10 Aug, 2016 4 commits
  16. 07 Aug, 2016 1 commit
  17. 26 Jul, 2016 4 commits
    • Duncan Coutts's avatar
      c5db03cc
    • Duncan Coutts's avatar
      Annotate exceptions in downloading packages · 49b31ed7
      Duncan Coutts authored
      Download errors are now put into the residual install plan, like other
      build errors.
      
      Fixes issue #3387
      49b31ed7
    • Duncan Coutts's avatar
      Refactor async download code · db785667
      Duncan Coutts authored
      Split things up a little so the generic async fetch can live with the
      other fetch utils. This also makes it easier to test.
      
      Change the exception handling so that any exception in fetching is
      propagated when collecting the fetch result.
      db785667
    • 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
  18. 25 Jul, 2016 2 commits
    • Duncan Coutts's avatar
      Remove the now-unused InstallPlan type args for result and failure · 0bb80be2
      Duncan Coutts authored
      These were used previously for the Installed and Failed package states,
      but these states are now gone.
      
      Importantly this now means that we can have a serialisable InstallPlan
      without the failure types having to be serialisable. This means we can
      use things like SomeException which is not serialisable. Since the
      traversal is done separately, the result of the traversal contains the
      failure values, but this result set does not have to be serialised.
      0bb80be2
    • Duncan Coutts's avatar
      Remove the now unused PlanPackage states · 7cb0844b
      Duncan Coutts authored
      We now just have the initial states, PreExisting and Configured. The
      Processing, Installed and Failed states are gone. We now do traversals
      separately from the InstallPlan, so we no longer need these states.
      7cb0844b