This project is mirrored from Pull mirroring updated .
  1. 17 Mar, 2017 7 commits
    • Edward Z. Yang's avatar
      Refactor MungedPackageId and PackageIndex. · f4ded04f
      Edward Z. Yang authored
      This makes the necessary changes to 4dc0f30fc36914ee2f01bde016bee98b8e0bb0bb
      to handle component configuring correctly.  It probably is a good step
      towards pkg:lib style dependencies.
      The big ideas:
      * There's a new AnnotatedId type, which is any identifier (like
        ComponentId), but also with a PackageId and ComponentName.
        It's a bit like ConfiguredId, but ConfiguredId is specialized
        for ComponentId.  There's a conversion function
      * We adopt a totally new strategy for handling MungedPackageId in
        InstalledPackageInfo.  Rather than store the munged package
        identifier in IPI, we NEVER store it, instead computing it
        from the package name and library name (which are stored.)
        There is now code to PARSE a munged package name into these
        two components, so that when we read 'name' we get the
        correct info.  The resulting code is splendidly clear.
      * Some places where we took a ComponentName (notably
        computeCompatPackageName) we now take 'Maybe UnqualComponentName'.
        This is more accurate, because compatibility package names are
        only computed for libraries, not other components.  Some code
        in Distribution.Backpack.ReadyComponent is partial now,
        but the invariants should hold up.
      * A number of places where MungedId was applied, I undid them.
        Most notable are macro generation (that should be PACKAGES,
        not components) and mkLegacyUnitId (since REALLY old style
        unit identifiers, we won't support internal libraries anyway.)
      * Many functions in PackageIndex are monomorphized to
        InstalledPackageInfo.  Fortunately cabal-install's usage
        still works.
      * Distribution/Client/SolverPlanIndex.hs, not used by anyone,
        got the axe.
      * Dependency solving has a hack to solve the problem of how to
        interpret installed internal libraries in the package database.
        The basic idea is that, although in most cases where we used
        a MungedId, we say it explicitly, in the SOLVER, we munge
        *installed package names* only, and keep the type PackageName.
        It's a hack, but the alternative is to write a lot more code.
        Note that is MORALLY PN is indeed a PackageName, since we really
        are solving for honest to goodness packages, not components!
        See Note [Index conversion with internal libraries] for more
      * ConfiguredId now records the ComponentName.  This is quite important,
        because we need to use it to figure out how we are going to phrase
        --dependency.  In fact, it is a miracle that this worked at all
        (and it only worked because of a very skeevy update to the PackageId
        in the creation of ConfiguredComponent).  Irritatingly, this must
        be a Maybe ComponentName, because a ConfiguredId MIGHT refer to
        a setup component. Very distressing.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
      Revert "Revert "Merge pull request #4382 from Ericson2314/munge"" · b0e6c311
      Edward Z. Yang authored
      This reverts commit 4774fb6558974a721176f1fb48d8ce7d43119251.
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Revert "Merge pull request #4382 from Ericson2314/munge" · b1b9d3b1
      Edward Z. Yang authored
      This reverts commit 332d809c, reversing
      changes made to 0c72bc88.
    • Edward Z. Yang's avatar
      Support --with-haddock. · 8b1ff6db
      Edward Z. Yang authored
      Signed-off-by: default avatarEdward Z. Yang <>
  2. 16 Mar, 2017 1 commit
  3. 15 Mar, 2017 1 commit
    • kristenk's avatar
      Use a more common type of conflict in the solver basic memory usage test. · ada7f93f
      kristenk authored
      The test previously caused the solver to backtrack because of a missing package.
      Missing packages are handled as a special case in the solver, so the test didn't
      exercise as much code as it could have.  This commit causes the solver to
      backtrack with a version conflict, which is a more common type of failure.
      Other tests continue to test the missing package case.
  4. 13 Mar, 2017 2 commits
  5. 12 Mar, 2017 3 commits
  6. 11 Mar, 2017 2 commits
  7. 10 Mar, 2017 7 commits
    • Edward Z. Yang's avatar
      Merge pull request #4386 from ezyang/pr/install-plan-refactor · 40318a77
      Edward Z. Yang authored
      ProjectPlanning refactor
    • Edward Z. Yang's avatar
      Refactor ProjectPlanning. · 9752f287
      Edward Z. Yang authored
      * toConfiguredComponents and friends are now monadic.  This means
        we can report a user-friendly error when we fail to find a
        dependency in the dependency map.  I had to rejigger a bit
        of the logic in ProjectPlanning since we were knot-tying through
        this function, but it all worked out.  This means
        that unbuildable_external_lib_deps is no more.
      * cc_internal_build_tools is no more; instead it's cc_exe_deps,
        which tracks ALL dependencies.  It also comes with a PackageId
        so we can build ConfiguredId cabal-install side.  This change
        propagates all the way to 'ReadyComponent'
      * ProjectPlanning: Instead of recomputing dependencies from scratch,
        we instead use the ElaboratedConfiguredPackages we just finished
        making to build the ComponentDeps.
      * ProjectPlanning now constructs a skeletal setupComponent.  This
        is used to setup the above with correct setup dependencies.
        In principle this component might also be used for building, but
        lots of functionality isn't written in yet.
      * filterExeMapDep is no more; it's all handled by Cabal now.
      * The ConfiguredComponentMap now handles both libraries and
        executables in one data structure.  This is nice.
      * compSetupDependencies is no more, because elaborated components
        never have custom setup.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
      Rewrite 'elaborateInstallPlan' for clarity. · 2454c0c5
      Edward Z. Yang authored
      There's still more refactoring to do, but here is a good
      first step.
      * New 'foldPlanPackage' for taking care of that annoying
        thing where you really wanted an OR-pattern on Configured/Installed
      * Big Note [SolverId to ConfiguredId]
      * elaborate(Lib|Exe)SolverId(') has been pared down to just
        elaborateLibSolverId and elaborateExeSolverId; call sites
        are responsible for projecting out the components they're actually
        interested in.  That gives us a new 'planPackageCacheFile' and
        'planPackageExePath' helper functions (which maybe should be
        lifted out.)
      * external_lib_dep_sids/etc bindings have been moved so they're
        closer together; easier to see.
      * Pile of new helper functions to help shorten code.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
      Merge pull request #4179 from dcoutts/target-handling · 56070e4c
      Edward Z. Yang authored
      Rework build target handling
    • Edward Z. Yang's avatar
      Merge pull request #4382 from Ericson2314/munge · 332d809c
      Edward Z. Yang authored
      Distinguish between true package names, and munged package names
    • Edward Z. Yang's avatar
      Merge pull request #4385 from Ericson2314/build-tools-forgot · 0c72bc88
      Edward Z. Yang authored
      A few things I forgot relating to build tool dependencies + slight test organization
    • Edward Z. Yang's avatar
  8. 09 Mar, 2017 5 commits
  9. 08 Mar, 2017 3 commits
  10. 07 Mar, 2017 9 commits