This project is mirrored from Pull mirroring updated .
  1. 06 Nov, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Add more fields to plan.json schema · d2f7845d
      Herbert Valerio Riedel authored
      This adds the following new fields:
       - `.compiler-id`
       - `.os`
       - `.arch`
       - `.install-plan[].pkg-name`
       - `.install-plan[].pkg-version`
       - `.install-plan[].pkg-src-sha256`
      Having separate "pkg-{name,version}" fields is desirable because the "id"-field
      is actually a UnitId which is supposed to be an opaque id which may not
      always be easily convertible into a PackageId via string operations.
      The "pkg-src-sha256" is generally useful to uniquely identify a
      source-tarball (when the package-id is not exact enough).
      Finally, the compiler-id/os/arch information is needed to determine the
      values of the respective impl()/os()/arch() predicates used in
      conditionals in .cabal files.
      Here's an example demonstrating the new fields:
            "cabal-version": "",
            "cabal-lib-version": "",
            "compiler-id": "ghc-8.0.1",
            "os": "linux",
            "arch": "x86_64",
            "install-plan": [
      	  "type": "configured",
      	  "id": "StateVar-",
      	  "pkg-name": "StateVar",
      	  "pkg-version": "",
      	  "flags": {},
      	  "style": "global",
      	  "pkg-src-sha256": "7ad68decb5c9a76f83c95ece5fa13d1b053e4fb1079bd2d3538f6b05014dffb7",
      	  "depends": [
      	  "exe-depends": [],
      	  "component-name": "lib"
                "type": "pre-existing",
                "id": "rts",
                "pkg-name": "rts",
                "pkg-version": "1.0",
                "depends": []
      	  "type": "configured",
      	  "id": "hackage-matrix-builder3-0.3-inplace-matrix-lib",
      	  "pkg-name": "hackage-matrix-builder3",
      	  "pkg-version": "0.3",
      	  "component-name": "lib:matrix-lib"
  2. 05 Nov, 2016 1 commit
    • Edward Z. Yang's avatar
      Add fingerprint of Generic representation when serializing. · ebcae71d
      Edward Z. Yang authored
      The idea is we can use Rep to get a full, structural representation
      of a type, and the fingerprint it using Typeable.  This gives
      us a very concise way of fingerprinting our Binary representation.
      This patch is not completely correct; the fingerprint needs
      to be overridable when someone writes a custom Binary instance.
      But this should be "good enough" in practice; we're not using
      these fingerprints to check anything security critical.
      TODO: Not sure if I have tagged all the call-sites which could
      profit from this.
      Fixes #4059.
      Signed-off-by: default avatarEdward Z. Yang <>
  3. 31 Oct, 2016 2 commits
  4. 28 Oct, 2016 1 commit
    • Edsko de Vries's avatar
      Add support for foreign libraries. · 382143aa
      Edsko de Vries authored
      A stanza for a platform library looks something like
          platform-library test-package
            type:                native-shared
            if os(Windows)
              options: standalone
              mod-def-file: TestPackage.def
            other-modules:       MyPlatformLib.Hello
            build-depends:       base >=4.7 && <4.9
            hs-source-dirs:      src
            c-sources:           csrc/MyPlatformLibWrapper.c
            default-language:    Haskell2010
      where native-shared means that we want to build a native shared library
      (.so on Linux, .dylib on OSX, .dll on Windows). The parser also
      recognizes native-static but this is not currently supported anywhere.
      The standalone option means that the we merge all library dependencies
      into the dynamic library (i.e., ghc options -shared -static), rather
      than make the created dynamic library just record its dependencies (ghc
      options -shared -dynamic); it is currently compulsory on Windows and
      unsupported anywhere else. The mod-def-file can be used to specify a
      module definition file, and is also Windows specific.
      There is a bit of refactoring in Build: gbuild is the old buildOrReplExe
      and now deals with both executables and platform libraries.
  5. 16 Oct, 2016 1 commit
  6. 12 Oct, 2016 1 commit
    • Duncan Coutts's avatar
      Infrastructure to maintain the project build status · 68a8534d
      Duncan Coutts authored
      We construct a PostBuildProjectStatus which has sets of package ids
      covering various properties, including:
       - out of date
       - definitely up to date
       - probably up to date
       - invalid due to dep changes
       - invalid due to direct build failure
      We also persistently keep track of the "probably up to date" set between
      In this patch we just calculate and maintain these things but don't yet
      use them except for debug output. The idea is it should be useful for
      things like maintaining the .ghc.environment, deleting stale build dirs
      or package registrations, maintaining exe wrapers/symlinks etc.
  7. 29 Sep, 2016 1 commit
    • Duncan Coutts's avatar
      Go back to the plan.json reflecting only env inputs · 602a5434
      Duncan Coutts authored
      In particular it will not reflect the status of the build, ie it will
      list all the source packages and their configuration but not say if
      they're already installed in the store.
      There's a slightly vauge principle at work here, that we should
      distinguish between build outputs and build ststus: build outputs
      should be (morally) pure functions of the environment, where as build
      status is about the degree to which the current cached outputs reflect
      the state of the inputs (ie are build outputs up to date or not).
      So in this case that means the plan.json is considered an output and
      thus it should not depend on the state of the store. We can certainly
      provide machine readable status info, but this should be a separate
  8. 24 Sep, 2016 1 commit
    • Duncan Coutts's avatar
      Update encodePlanAsJson for Installed package state · 9d6205e6
      Duncan Coutts authored
      The change in how we use the PreExisting vs Installed states means that
      we'll now have full details for all packages, rather than installed
      ones having only the subset of info available from the
      InstalledPackageInfo. So the 'type' field now can take the values
      "pre-existing", "configured" or "installed".
      Also do a little bit of tidying up.
  9. 20 Sep, 2016 1 commit
  10. 19 Sep, 2016 1 commit
    • Duncan Coutts's avatar
      Update encodePlanAsJson for Installed package state · 60ce97d2
      Duncan Coutts authored
      The change in how we use the PreExisting vs Installed states means that
      we'll now have full details for all packages, rather than installed
      ones having only the subset of info available from the
      InstalledPackageInfo. So the 'type' field now can take the values
      "pre-existing", "configured" or "installed".
      Also do a little bit of tidying up.
  11. 03 Sep, 2016 1 commit
  12. 23 Aug, 2016 1 commit
  13. 21 Aug, 2016 4 commits
    • Edward Z. Yang's avatar
      Tweaks to plan.json format · 4a9f11e6
      Edward Z. Yang authored
      - New "exe-depends" field
      - Dropped "depends" when it's a package; you can use
        "components" to get the information
      Signed-off-by: default avatarEdward Z. Yang <>
    • 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 <>
    • 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 <>
    • 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 <>
  14. 25 Jul, 2016 1 commit
    • 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.
  15. 22 Jul, 2016 1 commit
  16. 26 Apr, 2016 1 commit
  17. 10 Apr, 2016 2 commits
    • Edward Z. Yang's avatar
    • Duncan Coutts's avatar
      Maintain a plan.json file for external tools · 25d9b295
      Duncan Coutts authored
      This is (mostly) hvr's code.
      It produces an external representation of the elaborated install plan.
      The intention is for it to be used by external tools, editors etc, to
      find out relevant details of the project and package configuration and
      environment. It is updated whenever the elaborated install plan
      changes, so it always reflects the current state.
      Currently it only includes a modest subset of the details from the
      elaborated install plan, but the goal is to include all relevant details
      in a mostly-stable JSON format.
      Currently it's based on the elaborated install plan prior to improving
      the plan with packages from the store, but ultimately it will need to
      include information from both before and after the 'improvement' phase.