This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 07 Jan, 2017 1 commit
    • Robert Henderson's avatar
      Added qualifier to 'PackageConstraint' data type. · 79d562bf
      Robert Henderson authored
      Refactored PackageConstraint in two ways:
       1) split it into a package name and a 'PackageProperty' to make
          the code a bit cleaner;
       2) changed PackageName to 'Qualified PackageName'.
      
      Added a Binary instance for Qualifier in PackagePath.hs (needed
      for PackageConstraint).
      
      Added pretty-printing code for PackageConstraint.
      
      For now, all the code that creates a PackageConstraint just sets
      the qualifier to 'unqualified', so this commit will not change
      the external behaviour of cabal-install.
      79d562bf
  2. 18 Nov, 2016 1 commit
  3. 14 Nov, 2016 1 commit
  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. 26 Sep, 2016 1 commit
  7. 21 Sep, 2016 1 commit
    • Edward Z. Yang's avatar
      Don't solve for executables in legacy code path. · 9e99b3f4
      Edward Z. Yang authored
      There is a bug in `cabal configure`'s invocation of the solver in
      Distribution/Client/Configure.hs:
      
          standardInstallPolicy
              installedPkgIndex
              (SourcePackageDb mempty packagePrefs)
              [SpecificSourcePackage localPkg]
      
      We can see that the solver is given an EMPTY source package database.
      This is because we assume that everything you need from cabal configure
      is taken from the installed package index.
      
      But this is NOT true for executables, which never have an entry in the
      installed package index. So we SHOULD NOT solve for
      executables in the legacy codepath, since there isn't anything useful we
      can do with the info anyway.  This gets toggled using a new solver
      parameter SolveExecutables.
      
      I didn't bother with a test because this will be obsoleted by
      nix-local-build.
      
      Fixes #3875
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      9e99b3f4
  8. 10 Sep, 2016 1 commit
    • ttuegel's avatar
      Add `reconfigure` command · ae59bb3d
      ttuegel authored
      Fixes #2214 by adding a `reconfigure` command and invoking it whenever
      necessary. The last configure flags used are saved in a
      version-independent format so it should never be necessary for the user
      to reconfigure manually.
      ae59bb3d
  9. 06 Sep, 2016 4 commits
  10. 21 Aug, 2016 2 commits
  11. 17 Aug, 2016 1 commit
  12. 25 Jul, 2016 2 commits
  13. 23 Jul, 2016 1 commit
  14. 21 Jul, 2016 2 commits
  15. 19 Jul, 2016 2 commits
    • Edward Z. Yang's avatar
      Make a copy of InstallPlan named SolverInstallPlan. · a0891eba
      Edward Z. Yang authored
      Now we copy-paste the contents of InstallPlan into SolverInstallPlan,
      thus giving it a separate set of types.  For now, we don't do anything
      else, e.g., remove unnecessary functions or specialize.
      
      We need a new function 'fromSolverInstallPlan' akin to
      'mapPreservingGraph' which can take an InstallPlan from the
      old solver install plan to the new one.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      a0891eba
    • 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 <ezyang@cs.stanford.edu>
      49d69a90
  16. 11 Jul, 2016 1 commit
  17. 06 May, 2016 1 commit
  18. 27 Apr, 2016 1 commit
  19. 26 Apr, 2016 1 commit
  20. 19 Apr, 2016 1 commit
  21. 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 <ezyang@cs.stanford.edu>
      09528c2d
    • 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 <ezyang@cs.stanford.edu>
      cfb124f5
  22. 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 <ezyang@cs.stanford.edu>
      137075dc
  23. 03 Apr, 2016 1 commit
  24. 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 https://github.com/haskell/cabal/issues/3016.
      
      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.
      c72aa8db
  25. 24 Feb, 2016 1 commit
  26. 20 Feb, 2016 1 commit
  27. 19 Feb, 2016 2 commits
  28. 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
      Setup.hs.
      
      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.
      5b854abb
    • 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.
      41c20806
  29. 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 <ezyang@cs.stanford.edu>
      ef41f44e
  30. 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
      reasons:
      
      * 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
        demand).
      
      * 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.
      ba5c55c4