This project is mirrored from Pull mirroring updated .
  1. 19 Jul, 2016 1 commit
    • Edward Z. Yang's avatar
      Move SolverInstallPlan to its own module. · 49d69a90
      Edward Z. Yang authored
      This is a preparatory commit for giving SolverInstallPlan
      its own type.  We first start by moving the type synonyms
      for SolverInstallPlan into their own module, and update
      module references to point to them.
      TODO: Maybe this module should go in the Solver hierarchy
      rather than the client hierarchy?
      Signed-off-by: default avatarEdward Z. Yang <>
  2. 11 Jul, 2016 1 commit
  3. 06 May, 2016 1 commit
  4. 27 Apr, 2016 1 commit
  5. 26 Apr, 2016 1 commit
  6. 19 Apr, 2016 1 commit
  7. 06 Apr, 2016 2 commits
    • Edward Z. Yang's avatar
      Delete FakeMap. · 09528c2d
      Edward Z. Yang authored
      Compute 'UnitId' when we compute a 'ConfiguredPackage';
      consequently, we can eliminate 'FakeMap' (finally!)
      There is one hack remaining, which is that 'SolverInstallPlan'
      gins up fake unit IDs so that it can be keyed on UnitIds.
      But this data structure exists only very briefly before
      being converted into an 'InstallPlan' or 'ElaboratedInstallPlan'.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
      Introduce SolverId/SolverInstallPlan as solver output. · cfb124f5
      Edward Z. Yang authored
      Currently, dependency solving immediately produces an 'InstallPlan'
      which is then consumed by cabal install, or elaborated into
      an 'ElaboratedInstallPlan' for cabal new-build.  However, this
      translation is awkward, because the dependency solver knows nothing
      about 'UnitId's, yet an 'InstallPlan' must indexed by 'UnitId's.
      So there's a bit of faffing around to generate a "fake" unit id
      to satisfy the interface, and then eventually correct it to the
      right one.
      So this patch starts moving us in a better direction, by introducing
      a 'SolverInstallPlan', 'SolverPackage' and 'SolverId', intended
      to be generated by the solver.  Then 'configureInstallPlan' or
      'elaborateInstallPlan' elaborate this representation into the
      representation needed by the destination.
      The next step will be to generate the 'UnitId' during
      'configureInstallPlan', and then we can get rid of the fake map
      (so only Solver data types generate a fake identity, which
      is only temporary until we generate 'UnitId's.)
      Signed-off-by: default avatarEdward Z. Yang <>
  8. 05 Apr, 2016 1 commit
    • Edward Z. Yang's avatar
      Turn ReadyPackage into a newtype wrapper. · 137075dc
      Edward Z. Yang authored
      Previously, ReadyPackage was a ConfiguredPackage elaborated with
      a dependencies data structure which had InstalledPackageInfo
      rather than ConfiguredId. Well, it turned out that we only
      used the data from ConfiguredId! So that extra info is useless.
      Instead, ReadyPackage is now purely a newtype wrapper for type
      safety; a reminder that not all ConfiguredPackages can be built,
      only the ready ones.
      Signed-off-by: default avatarEdward Z. Yang <>
  9. 03 Apr, 2016 1 commit
  10. 05 Mar, 2016 1 commit
    • inaki's avatar
      Make the solver aware of pkg-config constraints · c72aa8db
      inaki authored
      When solving, we now discard plans that would involve packages with a
      pkgconfig-depends constraint which is not satisfiable with the current
      set of installed packages (as listed by pkg-config --list-all).
      This fixes
      It is possible (in principle, although it should be basically impossible
      in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to
      execute for various reasons, in particular because N is too large, so
      the command line becomes too long for the operating system limits.
      If this happens, revert to the previous behavior of accepting any
      install plan, regardless of any pkgconfig-depends constraints.
  11. 24 Feb, 2016 1 commit
  12. 20 Feb, 2016 1 commit
  13. 19 Feb, 2016 2 commits
  14. 29 Jan, 2016 2 commits
    • Duncan Coutts's avatar
      SetupWrapper: allow being explicit about the Cabal spec version · 5b854abb
      Duncan Coutts authored
      A new option in SetupScriptOptions to specify exactly what version of
      the Cabal spec we believe we're using when we're talking to the
      Currently the version of cabal to use is guessed by the SetupWrapper
      code based on the useCabalVersion version range and what versions are
      installed in the ambient package environment, and cached state of
      whatever an existing compiled Setup used.
      When an explicit useCabalSpecVersion is given, all of these heuristics
      are short cut and we use exactly the version we're told to use. In this
      case it's the responsibility of the caller to useDependencies with a
      suitable Cabal lib version, or otherwise know that we'll be using the
      self or internal setup methods.
      This approach goes along with the idea of deciding up front (and in a
      deterministic way) what setup deps to use (using defaults if needed),
      rather than deciding based on what's currently in the user environment.
      In the current code paths, useCabalSpecVersion is Nothing, so no change
      in behaviour yet.
    • Duncan Coutts's avatar
      Split useDependenciesExclusive behaviour into two independent options · 41c20806
      Duncan Coutts authored
      The useDependenciesExclusive in the SetupWrapper controls two bits of
      behaviour: if the deps given for building the Setup.hs are the only
      ones allowed, and if we should make version cpp macros available when
      building the Setup.hs. Currently we either want both behaviours or
      neither behaviour. We want them in the case that a package declares a
      custom setup with explicit dependencies.
      It makes sense however to have one behaviour without the other. In
      particular it makes sense if we want to implement a policy where we
      supply default dependencies for older packages that have custom setup
      scripts but don't specify any deps. In this case we want to make the
      default deps exclusive, but we don't want to use the version macros,
      because those ought to be reserved for packages that are doing the right
      thing and opting-in to the new world of explicitly specified setup deps.
      So this patch splits the behaviour into two controls, but still uses
      both together so there's no change in behaviour yet.
  15. 16 Jan, 2016 1 commit
    • Edward Z. Yang's avatar
      Distinguish between component ID and unit ID. · ef41f44e
      Edward Z. Yang authored
      GHC 8.0 is switching the state sponsored way to specify
      linker names from -this-package-key to -this-unit-id, so
      it behooves us to use the right one.  But it didn't make
      much sense to pass ComponentIds to a flag named UnitId,
      so I went ahead and finished a (planned) refactoring
      to distinguish ComponentIds from UnitIds.
      At the moment, there is NO difference between a ComponentId
      and a UnitId; they are identical.  But semantically, a
      component ID records what sources/flags we chose (giving us enough
      information to typecheck a package), whereas a unit ID records
      the component ID as well as how holes were instantiated
      (giving us enough information to build it.)  MOST code
      in the Cabal library wants unit IDs, but there are a few
      places (macros and configuration) where we really do
      want a component ID.
      Some other refactorings that got caught up in here:
          - Changed the type of componentCompatPackageKey to String, reflecting the
            fact that it's not truly a UnitId or ComponentId.
          - Changed the behavior of CURRENT_PACKAGE_KEY to unconditionally
            give the compatibility package key, which is actually what you
            want if you're using it for the template Haskell trick.  I also
            added a CURRENT_COMPONENT_ID macro for the actual component ID,
            which is something that the Cabal test-suite will find useful.
          - Added the correct feature test for GHC 8.0 ("Uses unit IDs").
      Signed-off-by: default avatarEdward Z. Yang <>
  16. 07 Jan, 2016 1 commit
    • Edsko de Vries's avatar
      Introduce RepoContext · ba5c55c4
      Edsko de Vries authored
      The RepoContext encapsulates the list of repositories, as well as some
      associated state. In particular, it also encapsulates the HttpTransport, which
      will be initialized on demand and cached thereafter.  This is important for two
      * For the hackage-security integration: in order to be able to use cabal's own
        HttpTransport API for the secure repo, we need to have access to that
        transport when we initialize the repo, but as things stood that was not
        possible (cabal was initializing repos ahead of time but the transport on
      * For the integration with the nix-local-branch it is important that the Repo
        type remains Serializable. By passing RepoContext rather than a list of
        Repos, we can leave RepoSecure serializable and separately maintain a mapping
        from cabal's Repo type to hackage-security's (stateful) Repository type.
  17. 09 Oct, 2015 1 commit
    • Edward Z. Yang's avatar
      Implement ComponentId, replacing PackageKey and InstalledPackageId. · b083151f
      Edward Z. Yang authored
      Today in Cabal, when you build and install a package, it is
      uniquely identified using an InstalledPackageId which is computed
      using the ABI hash of the library that was installed.  There
      are few problems with doing it this way:
          - In a Nix-like world, we should instead uniquely identify
            build products by some sort of hash on the inputs to the
            compilation (source files, dependencies, flags).  The ABI
            hash doesn't capture any of this!
          - An InstalledPackageId suggests that we can uniquely identify
            build products by hashing the source and dependencies of
            a package as a whole.  But Cabal packages contain many components:
            a library, test suite, executables, etc.  Currently, when
            we say InstalledPackageId, we are really just talking about
            the dependencies of the library; however, this is unacceptable
            if a Cabal package can install multiple libraries; we need
            different identifiers for each.
          - We've also needed to compute another ID, which we've called
            the "package key", which is to be used for linker symbols
            and type equality GHC-side.  It is confusing what the distinction
            between this ID and InstalledPackageIds are; the main reason
            we needed another ID was because the package key was needed
            prior to compilation, whereas the ABI hash was only available
      This patch replaces InstalledPackageId and PackageKey with a
      new identifier called ComponentId, which has the following
          - It is computed per-component, and consists of a package
            name, package version, hash of the ComponentIds
            of the dependencies it is built against, and the name
            of the component.  For example, "foo-0.1-abcdef" continues
            to identify the library of package foo-0.1, but
            "foo-0.1-123455-foo.exe" would identify the executable,
            and "foo-0.1-abcdef-bar" would identify a private sub-library
            named bar.
          - It is passed to GHC to be used for linker symbols and
            type equality.  So as far as GHC is concerned, this is
            the end-all be-all identifier.
          - Cabal the library has a simple, default routine for computing
            a ComponentId which DOES NOT hash source code;
            in a later patch Duncan is working on, cabal-install can
            specify a more detailed ComponentId for a package
            to be built with.
      Here are some knock-on effects:
          - 'id' is a ComponentId
          - 'depends' is now a list of ComponentIds
          - New 'abi' field to record what the ABI of a unit is (as it is no longer
            computed by looking at the output of ghc --abi-hash).
          - The 'HasInstalledPackageId' typeclass is renamed to
          - GHC 7.10 has explicit compatibility handling with
            a 'compatPackageKey' (an 'ComponentId') which is
            in a compatible format.  The value of this is read out
            from the 'key' field.
      Signed-off-by: default avatarEdward Z. Yang <>
  18. 21 Aug, 2015 1 commit
  19. 31 Jul, 2015 2 commits
  20. 30 Jul, 2015 4 commits
  21. 06 Apr, 2015 2 commits
    • Edsko de Vries's avatar
      Actually _use_ setup deps in configure and co · ba317c2c
      Edsko de Vries authored
      The only problematic thing is that when we call `cabal clean` or `cabal
      haddock` (and possibly others), _without_ first having called `configure`, we
      attempt to build the setup script without calling the solver at all. This means
      that if you do, say,
          cabal configure
          cabal clean
          cabal clean
      for a package with a custom setup script that really needs setup dependencies
      (for instance, because there are two versions of Cabal in the global package DB
      and the setup script needs the _older_ one), then first call to `clean` will
      succeed, but the second call will fail because we will try to build the setup
      script without the solver and that will fail.
    • Edsko de Vries's avatar
      Add ComponentSetup to ComponentDeps · 1effd34b
      Edsko de Vries authored
      Although we don't use the new setup dependency component anywhere yet, I've
      replaced all uses of CD.flatDeps with CD.nonSetupDeps. This means that when we
      do introduce the setup dependencies, all code in Cabal will still use all
      dependencies except the setup dependencies, just like now. In other words,
      using the setup dependencies in some places would be a conscious decision; the
      default is that we leave the behaviour unchanged.
  22. 31 Mar, 2015 1 commit
    • Edsko de Vries's avatar
      Keep fine-grained deps after solver · 87a79be9
      Edsko de Vries authored
      The crucial change in this commit is the change to PackageFixedDeps to return a
      ComponentDeps structure, rather than a flat list of dependencies, as long with
      corresponding changes in ConfiguredPackage and ReadyPackage to accomodate this.
      We don't actually take _advantage_ of these more fine-grained dependencies yet;
      any use of
      is now a use of
         CD.flatDeps . depends
      but we will :)
      Note that I have not updated the top-down solver, so in the output of the
      top-down solver we cheat and pretend that all dependencies are library
  23. 06 Mar, 2015 1 commit
  24. 10 Dec, 2014 1 commit
    • Luite Stegeman's avatar
      use CompilerInfo rather than CompilerId for resolving flags and · 7d91b773
      Luite Stegeman authored
      path templates.
      CompilerInfo contains more information about the compiler than
      CompilerId, which just stores the flavour and version. In particular,
      CompilerInfo knows an AbiTag, which can be used to tell binary
      incompatible results from the same compiler apart, and detailed
      information about supported languages and extensions.
      Some fields in CompilerInfo may be left unknown (Nothing). This can
      be used in the future to allow partially resolving configurations
      based on supported languages or extensions.
  25. 30 Oct, 2014 1 commit
  26. 27 Aug, 2014 1 commit
  27. 02 Aug, 2014 1 commit
  28. 02 May, 2014 1 commit
  29. 19 Dec, 2013 2 commits
  30. 06 Dec, 2013 1 commit
  31. 05 Dec, 2013 1 commit