This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 23 Oct, 2016 1 commit
  2. 22 Oct, 2016 2 commits
  3. 04 Oct, 2016 1 commit
  4. 03 Oct, 2016 2 commits
  5. 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
  6. 27 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `PackageName` type opaque (#3896) · dabd9d98
      Herbert Valerio Riedel authored
      When looking at heap-profiles of `cabal-install`, the `(:)` constructor
      stands out as the most-allocated constructor on the heap.
      
      Having to handle 10k+ package names contributes to the allocation
      numbers, especially on 64bit archs where ASCII `String`s have a 24 byte
      per character footprint.
      
      This commit is a preparatory commit to pave the way for changing
      `PackageName`'s internal representation to something like
      `ShortByteString` (which is essentially a thin wrapper around primitive
      `ByteArray#`s which themselves have have an overhead of 2 words + one
      byte per ASCII character rounded up to nearest word) which would allow
      to reduce the memory footprint by a full order of magnitude, as well as
      reduce pointer chasing and GC overhead.
      dabd9d98
  7. 10 Sep, 2016 1 commit
  8. 07 Sep, 2016 1 commit
  9. 21 Aug, 2016 1 commit
    • Edward Z. Yang's avatar
      Solve for, build, and add to path build-tools dependencies. · c0a48602
      Edward Z. Yang authored
      
      
      This fixes #220: new-build now builds, installs and adds executables to
      PATH automatically if they show up in 'build-tools'.  However, there is
      still more that could be done: the new behavior only applies to a
      specific list of 'build-tools' (alex, happy, etc) which Cabal recognizes
      out of the box.  The plan is to introduce a new 'tool-depends' field to
      allow dependencies on other executables as well.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      c0a48602
  10. 22 Jul, 2016 1 commit
  11. 21 Jul, 2016 1 commit
  12. 19 Jul, 2016 2 commits
    • Edward Z. Yang's avatar
      Specialize and delete code not needed by SolverInstallPlan. · 07bb6d15
      Edward Z. Yang authored
      
      
      Now we monomorphize SolverInstallPlan so that its data structures
      are non-parametric, and delete functions that are not needed.
      Specifically:
      
          - GenericPlanPackage -> SolverPlanPackage, lose the
            type parameters, lose the Processing/Installed/Failed
            constructors (this makes some partial functions total! Yay!)
      
          - GenericInstallPlan -> SolverInstallPlan
      
          - PlanProblem -> SolverPlanProblem
      
          - Deleted ready, processing, completed, failed,
            preexisting
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      07bb6d15
    • 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
  13. 16 Jul, 2016 1 commit
  14. 27 Jun, 2016 1 commit
  15. 06 May, 2016 1 commit
  16. 27 Apr, 2016 1 commit
  17. 26 Apr, 2016 1 commit
  18. 24 Apr, 2016 1 commit
  19. 23 Apr, 2016 1 commit
  20. 19 Apr, 2016 1 commit
  21. 13 Apr, 2016 1 commit
  22. 06 Apr, 2016 1 commit
    • 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
  23. 03 Apr, 2016 2 commits
  24. 31 Mar, 2016 1 commit
  25. 29 Mar, 2016 2 commits
    • Edward Z. Yang's avatar
      Implement "convenience libraries", fixes #269. · 2040c1c9
      Edward Z. Yang authored
      
      
      Convenience libraries are package-private libraries
      that can be used as part of executables, libraries, etc
      without being exposed to the external world.  Private
      libraries are signified using the
      
          library foo
      
      stanza.  Within a Cabal package, the name convenience library
      shadows the conventional meaning of package name in
      build-depends, so that references to "foo" do not indicate
      foo in Hackage, but the convenience library defined in the
      same package. (So, don't shadow Hackage packages!)
      
      This commit implements convenience libraries such that they
      ARE installed the package database (this prevents us from
      having to special case dynamically linked executables);
      in GHC 7.10 and later they are installed under the same
      package name as the package that contained them, but have
      a distinct "component ID" (one pay off of making the distinction
      between component IDs and installed package IDs.)
      
      There is a "default" library which is identified by the fact
      that its library name coincides with the package name.  There
      are some new convenience functions to permit referencing this.
      
      There are a few latent bugs in this commit which are fixed
      in later commits in this patchset.  (Those bugfixes required
      a bit of refactoring, so it's clearer if they're not
      with this patch.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      2040c1c9
    • kristenk's avatar
      Start adding solver quickcheck tests · ce9e82cc
      kristenk authored
      ce9e82cc
  26. 07 Mar, 2016 1 commit
  27. 06 Mar, 2016 1 commit
  28. 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
  29. 19 Feb, 2016 1 commit
  30. 16 Jan, 2016 2 commits
    • 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
    • kristenk's avatar
      Change default flag value to True in solver DSL. · 2bac1fe7
      kristenk authored
      This default is consistent with Cabal.
      2bac1fe7
  31. 14 Jan, 2016 3 commits
  32. 26 Dec, 2015 1 commit