This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 10 Apr, 2016 9 commits
    • Duncan Coutts's avatar
      Clarify a TODO · d3f5f783
      Duncan Coutts authored
      The solverSettingFlagAssignment does not need to be eliminated, it's ok
      to have both, but make a note that it does need validating at some
      point.
      d3f5f783
    • Duncan Coutts's avatar
      Make the $prog-options/location config fields per-package · bebbe9e6
      Duncan Coutts authored
      We need to be able to specify program options and locations on a
      per-pakage basis. Of course we can still specify them for all local
      packages.
      
      Note that these options are not actually used yet, which is why this
      patch can be so small. Using them is next.
      bebbe9e6
    • Duncan Coutts's avatar
      Make flag assignments per-package · ef04b699
      Duncan Coutts authored
      Move the FlagAssignment from the project-wide all-packages config to the
      per-package config.
      
      Initially it had been easier to do it globally since it gets used as a
      solver setting rather than as the other per-package config items, but
      obviously it is supposed to be per-package.
      
      So the flags field in the config top-level now applies to all local
      packages. And it can also be specified in package-specific sections.
      
      We don't yet check that any of the flags specified actually make sense
      for either the local packages or for the specific packages.
      ef04b699
    • Duncan Coutts's avatar
      Use MapMappend monoid for the package-specific config · 978aea20
      Duncan Coutts authored
      It's a Map PackageName PackageConfig (or LegacyPackageConfig) so the
      correct monoid instance is to merge the PackageConfig values.
      978aea20
    • Duncan Coutts's avatar
      Introduce (but not yet use) monoids MapLast and MapMappend · 916a502a
      Duncan Coutts authored
      These are newtype wrappers with different Monoid instances. This is for
      following our more recent approach to the Monoid instances of our config
      types where rather than having custom mappen methods, we derive generic
      Monoid/Semigroup instances and rely on using special types like NubList
      for individual fields that need different mappend behaviour.
      
      The Map type has mappend behaviour that is not usually what we want for
      our configuration types. The normal Map mappend prefers the first
      argument over the second when keys overlap between the two maps. We
      normally want later things to either override or to extend, like our
      normal Flag (like Last) monoid or list monoid. So MapLast is a Map with
      Flag/Last-like behaviour, ie flip Map.union, while MapMappend is a Map
      that merges values when keys overlap, ie Map.unionWith (<>). The latter
      helps when the Map values are lists or further records.
      916a502a
    • Duncan Coutts's avatar
      e8e29025
    • Duncan Coutts's avatar
      Correct path handling for package dirs in project files · f8d3d141
      Duncan Coutts authored
      Both relative and absolute paths. That is, things like:
      
      packages: this/
                ~/hacking/that/
      f8d3d141
    • Edward Z. Yang's avatar
      a825393b
    • Edward Z. Yang's avatar
      6da012e8
  2. 08 Apr, 2016 21 commits
  3. 07 Apr, 2016 2 commits
  4. 06 Apr, 2016 3 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
    • Edward Z. Yang's avatar
      Make AppVeyor less chatty. · 1b0080d0
      Edward Z. Yang authored
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      1b0080d0
  5. 05 Apr, 2016 5 commits