This project is mirrored from Pull mirroring updated .
  1. 05 May, 2017 1 commit
  2. 04 May, 2017 1 commit
  3. 01 May, 2017 1 commit
    • kristenk's avatar
      Uncomment --independent-goals flag. · 4ee0df39
      kristenk authored
      --independent-goals could be useful for using local packages as setup or
      build-tool dependencies in new-build.  See #4295 for an example of a dependency
      problem that requires --independent-goals.  The flag is off by default.
  4. 30 Apr, 2017 1 commit
    • Edward Z. Yang's avatar
      More accurate "registration needed?" calculation for packages. · fc1e08e6
      Edward Z. Yang authored
      Previously, we stated that registration was needed if any build target
      was a library.  Actually, this is not enough: if we have a build target
      on an executable which in turn depends on the library, we must register
      To actually get this information, I had to refactor ComponentsGraph to
      return the actual *graph*, so I could do a reverse closure on it, giving
      me the set of components that actually depend on the library.  That info
      then gets plumbed through ElaboratedPackage and then used to determine
      if registration is necessary.
      Fixes #4450, but it's possible there is another variant of the bug
      that occurs if the executable to be built does NOT depend on the
      I also needed to add a new hasNewBuildCompatBootCabal helper to the
      test suite to check if we can actually build the Custom setup
      with the boot Cabal.
      Signed-off-by: default avatarEdward Z. Yang <>
  5. 28 Apr, 2017 1 commit
  6. 01 Apr, 2017 2 commits
    • Duncan Coutts's avatar
      Planning and building phases use the new store functions · b75a1624
      Duncan Coutts authored
      This should mean that concurrent updates to the store are now safe.
      In practice it means working on separate projects at the same time is
      safe, not concurrent builds within the same project.
    • Duncan Coutts's avatar
      Create package DBs in building phase not planning phase · 83a42061
      Duncan Coutts authored
      Adjust things so that instead of creating the store package db during
      planning, we instead create them at the beginning of the building phase
      along with the other package dbs we create at that point. That is,
      create it in a write operation rather than in what is morally a read
      Originally we had to do it in the planning phase because we used to read
      the compiler package db to see what was installed, whereas now we just
      use the store dir listing.
      In fact we were already creating some package dbs during the building
      phase, just not all of them, so this cleans things up in that respect.
  7. 26 Mar, 2017 1 commit
  8. 24 Mar, 2017 1 commit
    • Duncan Coutts's avatar
      Refactor: split StoreDirLayout out of CabalDirLayout · 045c7c9a
      Duncan Coutts authored
      So we have a spec of the layout of the store, independent of the
      instance of the store within ~/.cabal/store. This will make new store
      handling code cleaner by not entangling it with other global ~/.cabal
      We may also in future want to allow global and per-user stores, and we
      certainly want the ability to specify a store location outside of
      ~/.cabal (though this could be done with the existing code too).
  9. 20 Mar, 2017 1 commit
    • Edward Z. Yang's avatar
      More accurately determine monitors to monitor. · a9052da2
      Edward Z. Yang authored
      Previously, we used the solver dependencies to figure out
      what to monitor, but this lead to a failure mode where we
      would also monitor the monitor files associated with the
      test suite, which we really shouldn't do.
      This patch pushes the monitor file calculation later until
      the build step, at which point we know exactly what our
      dependencies are, and monitor those precisely.
      Fixes #4405.
      Signed-off-by: default avatarEdward Z. Yang <>
  10. 17 Mar, 2017 1 commit
    • 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 <>
  11. 11 Mar, 2017 2 commits
  12. 10 Mar, 2017 2 commits
    • 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 <>
  13. 08 Mar, 2017 1 commit
  14. 07 Mar, 2017 5 commits
    • Edward Z. Yang's avatar
      Fix new-build exe target bug. · dd2731f6
      Edward Z. Yang authored
      I noticed this bug when porting a (dead code) test case
      for new-build on executables to the new test suite; I
      noticed that if you do a fresh new-build on a project
      with lib and executable, specifying to only build the
      executable, AND the executable doesn't depend on the lib,
      new-build incorrectly decides to try to register the lib
      even though no lib was actually built.
      This is because "needs registration" was computed pre-pruning.
      I turned elabNeedsRegistration into a function that looks
      at the post-pruning elabBuildTargets to determine if we
      are actually going to build a library or not.
      This was actually a bit tricky (I introduced a regression)
      with regards to handling when there are NO targets.  We have
      a regression test for this now.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Duncan Coutts's avatar
      Clarify a minor bit of logic in availableTargets · 1022c145
      Duncan Coutts authored
      The not withinPlan case cannot occur in the non-optional stanza cases,
      so remove the test to avoid confusingly suggesting it is possible.
    • Duncan Coutts's avatar
      Preserve empty packages in the plan for error reporting · 2da8b18d
      Duncan Coutts authored
      In the corner case that a package has no components then if we allow it
      to be handled as normal per-component nodes then the whole package would
      vanish from the plan, which breaks later error reporting. Instead we
      keep 0-component packages as whole-package nodes (as we do in a few
      other cases like old Cabal versions or custom Setup scripts).
      Later on we need to be able to look up package names that users have
      requested and find what components they contain. It's ok to report that
      a package has no components, but it's not ok to report that the package
      does not exist at all. Hence it's important to preserve these packages
      in the plan.
      If we ever move fully to a per-component plan then we will need to
      revisit this issue of how to represent packages with no components.
    • Duncan Coutts's avatar
      Adjust multiple target error case for run and repl commands · 2dc23405
      Duncan Coutts authored
      The run and repl commands only work with a single component as targets.
      When the user gives multiple target selectors that refer to distinct
      targets then we must report an error. It turns out that the information
      we already had was not really sufficient to construct a helpful error
      message. The information we had was the component targets that were
      actually selected, but we actually want to know the target selectors
      that gave rise to the selection of multiple targets.
      So this patch extends the information we collect in the resolveTargets
      function and stashes this info in the TargetProblemMultipleTargets
      constructor, which will enable construction of useful error messages.
    • Duncan Coutts's avatar
      Rename TargetProblem types and change a few related things · a8489be7
      Duncan Coutts authored
      Each Cmd* module defines its own type for representing the error
      conditions in selecting package and component targets. Each one has a
      constructor for the problems that are common to them all, which is
      shared in the ProjectOrchestration module.
      Rename these types so that ProjectOrchestration defines the type
      TargetProblemCommon and each of the others defines their own local type
      each named TargetProblem.
      Also make one step closer to proper error reporting for all these types
      by using die' and verbosity appropriately. Remove the old unused and
      incomplete error reproting code for TargetProblemCommon.
      Add a few Eq and Ord instances while we're at it. They'll be needed for
      testing and other things.
  15. 06 Mar, 2017 1 commit
    • John Ericson's avatar
      Clean up PreExistingComponent · 66736e96
      John Ericson authored
      It no longer hacks around build-depends: that code has been moved to
      Backpack.Configure, and will be removed altogether with LibDependency
  16. 27 Feb, 2017 12 commits
    • Duncan Coutts's avatar
      Extend DistDirLayout with project root and cabal.project · 2b26e75b
      Duncan Coutts authored
      So the DistDirLayout now contains the root dir of the project as a
      whole, which eliminates the need to pass it separately in several cases.
      It also contains the location of the cabal.project file, which again
      avoids having to pass it around.
      In part these changes were to allow the elimination of uses of the
      legacy config types in the new-build code. The idea is that the legacy
      config types are only used by conversion into the new config types, and
      then only the new types are used in the new code.
    • Duncan Coutts's avatar
      Spelling and grammar in comments · 8be0062c
      Duncan Coutts authored
    • Duncan Coutts's avatar
      Add and improve a couple comments · 942fc0e5
      Duncan Coutts authored
    • Duncan Coutts's avatar
      Add a new 'all' form of target selector · df8ccce1
      Duncan Coutts authored
      Extend TargetSelector with a TargetAllPackages constructor with the
      corresponding concrete command line syntax 'all'. The interpretation of
      this is extended for all commands to be the same as if the list of all
      packages local to the project were given.
      Since the concrete syntax for the meta-target 'all' can in principle
      clash with a package 'all' or a component 'all', this short form of
      syntax is made to be ambigious with the existing short forms for
      packages or components, and new more qualified forms are added.
      This means that a user writing 'cabal build all' in a project where
      there is a local package 'all' or a component 'all' in the package in
      the cwd (but not any package 'all' as a dependency or any component
      'all' in any package other than the one in the cwd), will be informed
      that the syntax is ambigious and will be told the more qualified forms
      of the possible targets. These would be ':all' and 'pkg:all'. The use of
      the usual ':' separator with an empty string is the explicit indicator
      of a meta namespace. Since 'pkg:all' itself is also potentially
      ambigious with a package named 'pkg' containing a component 'all' then
      there is a further qualified form ':pkg:all' to select the package named
      This more qualified syntax need only be used in these highly unusual
      ambigious cases and the user will be informed. The intention, as has
      been the case previously, is to allow a normal syntax that is short and
      convenient but potentially ambigious in rare cases, while still allowing
      all cases to be expressed unambigiously.
    • Duncan Coutts's avatar
      Split getting project config from making the install plan · a05b8a07
      Duncan Coutts authored
      Previously we had a rebuildInstallPlan that does everything up to
      producing the elaborated install plan. This included reading the project
      config and all the local package description files etc.
      It is useful to split this latter aspect out separately. The reason for
      this is that we would really prefer to resolve command line build
      targets without first having to run the solver and produce the
      elaborated install plan. We would prefer to be able to report mistakes
      in the build targets more or less instantly rather than having to wait
      many seconds (or sometime more) before being able to report problems.
      Worse, with the current scheme the solver may fail to find a solution
      and so we'll end up reporting that rather than the problem with the
      user's build target. Indeed problems with a build target are most likely
      to happen when the project config is messed up (or not what users
      expect, or before they understand the model) and those are the cases
      where it's most likely that there is no project solution.
      So this is a step towards being able to do all target resolution prior
      to solving.
    • Duncan Coutts's avatar
      Move rendering of CannotPruneDependencies to CmdBuild · 259a88cd
      Duncan Coutts authored
      The --only-dependencies it is only used in build, so we move the
      rendering of the errors that arise from that to that build command
      module so the error message text can be more context specific.
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      New infrastructure for collecting info on available targets · d02bc2f0
      Duncan Coutts authored
      This is one major part of a new implementation of translating from high
      level user intentions of what to build into the detail of what specific
      components to build.
      This part collects and summarises information on what component are
      available as targets. Each available target one has enough status info
      to determine if we can possibly select the target or if not why not.
      This information will be used by each command (build, repl, test etc) to
      select the specific targets that a user intention refers to (and to
      provide them enough information to be able to produce reasonable error
      Collecting and summarising this info is unfortunately non-trivial
      because as part of install plan elaboration we omit components that
      cannot be built but these are still components that users could try to
      refer to, so we have to reconstruct the info about the omitted
      components. It's plausible that we may want to revise the elaborated
      install plan representation to make this easier.
    • Duncan Coutts's avatar
      Change pruneInstallPlanToTargets to take ComponentTargets · bd177197
      Duncan Coutts authored
      Previously it took the specification for the targets to build in terms
      of PackageTarget which is a high-ish level specification of which
      components to build. It is high level in the sense that it says things
      like BuildDefaultComponents which still have to be elaborated into the
      specific components.
      This elaboration from the higher level intention of what to build into
      what components to build specifically has to vary between different
      commands (build, repl, run, test, bench) and it can also fail. These
      features make it not a good fit to do within plan pruning. Instead it
      is better to have plan pruning take the lower level specification of
      what to build in terms of components and to do the conversion of high
      level to low level separately. That will allow us to do it differently
      for different commands and deal with failures better.
      This patch does one step: it changes pruneInstallPlanToTargets from
      taking [PackageTarget] to [ComponentTarget] and as an intermediate step
      in refactoring it converts the existing elaboratePackageTargets code to
      convert from the [PackageTarget] to [ComponentTarget] which is then used
      by the calling code in ProjectOrchestration. The next step will be to
      replace the elaboratePackageTargets with something more flexible and
      that can handle errors better.
    • Duncan Coutts's avatar
      Refactoring: make nubComponentTargets top level · 5fbf262c
      Duncan Coutts authored
      And push compatSubComponentTargets inside nubComponentTargets. The
      motivation for this is we'll be exporting nubComponentTargets and using
      it from the ProjectOrchestration as part of revised target handling.
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      Split one of the pruneInstallPlanToTargets passes for clarity · 0b432931
      Duncan Coutts authored
      The pruneInstallPlanToTargets function had two main passes. Split the
      first pass into two passes. This simplifies things a bit and helps
      clarify the fact that setting the root targets is something we do prior
      to taking the dep closure.
  17. 24 Feb, 2017 1 commit
  18. 19 Feb, 2017 4 commits
  19. 08 Feb, 2017 1 commit
    • Duncan Coutts's avatar
      Change Graph.fromList to fromDistinctList and fix conseqeunces · 1440ffd5
      Duncan Coutts authored
      It's really an error to try and build a graph where you have duplicate
      node keys, so remove Graph.fromList and add Graph.fromDistinctList. This
      check is always on, not just an assertion, becuase we get it for free
      given the way Maps can be constructed.
      All uses of Graph.fromList are ok to convert to fromDistinctList.