This project is mirrored from Pull mirroring updated .
  1. 12 Apr, 2016 11 commits
  2. 10 Apr, 2016 20 commits
    • Edward Z. Yang's avatar
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      Add a TODO and correct a typo · 550318e9
      Duncan Coutts authored
    • Duncan Coutts's avatar
      Add the new configure, build and repl commands · d040d8b8
      Duncan Coutts authored
      The three commands are all implemeted in terms of the planning and
      execution infrastracture added previously. The orchestration of that
      infrastructure is shared between the commands in another module.
      Also add a new CLI target parsing/recognising/disambiguating module,
      similar to the one in the Cabal lib used for the 'build' command, but
      extended to cover multiple packages in a project rather than just
      components within a package.
    • Duncan Coutts's avatar
      Maintain a plan.json file for external tools · 25d9b295
      Duncan Coutts authored
      This is (mostly) hvr's code.
      It produces an external representation of the elaborated install plan.
      The intention is for it to be used by external tools, editors etc, to
      find out relevant details of the project and package configuration and
      environment. It is updated whenever the elaborated install plan
      changes, so it always reflects the current state.
      Currently it only includes a modest subset of the details from the
      elaborated install plan, but the goal is to include all relevant details
      in a mostly-stable JSON format.
      Currently it's based on the elaborated install plan prior to improving
      the plan with packages from the store, but ultimately it will need to
      include information from both before and after the 'improvement' phase.
    • Edward Z. Yang's avatar
      Fix #3019, use sdist to find files to monitor. · 1f663390
      Edward Z. Yang authored
      As a refactoring, this moves allPackageSourceFiles from
      Distribution.Client.Sandbox.Timestamp to
      Distribution.Client.SrcDist, makes it thread safe, and has
      it return files relative to the source directory.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Duncan Coutts's avatar
      Check for specifying compiler program locations per-package · 3a69f2ea
      Duncan Coutts authored
      You're not allowed to specify a different compiler program for different
      packages within the same project. Given that in general we allow
      specifying config about programs on a per-package basis this needs a
      specific check.
      Also add a place and a TODO for Future work in this area which is to
      check up front that we can find the programs and to monitor them for
      changes. Also, currently none of the program config ends up in the
      package hashes, so it doesn't cause them to be rebuilt.
    • Duncan Coutts's avatar
      Pass per-package program config through · 20d00264
      Duncan Coutts authored
      That is, the --with-$PROG program locations, the --$PROG-option(s)
      program arguments and the --extra-prog-path search paths. These can be
      passed on the command line or specified in the cabal.project file.
      In the project file they can be specified for all local package or on a
      per-package basis.
      The compiler and its related programs are handled specially. Their
      location cannot be specified independently for each package. A
      subsequent patch will add the checks for this. Otherwise we just pass
      the program config though.
      Program options specified on the command line currently apply to all
      local packages, not just the targets of the command. We may want to
      revisit this.
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      Split the ProjectPlanning types out into another module · dd2da8de
      Duncan Coutts authored
      Not needed immediately, but we'll need it eventually to avoid import
      cycles later. No other changes, just moving things around and pruning
      imports and language extensions.
    • Duncan Coutts's avatar
      Rename pkgConfigProgramDb/CompilerProgs to clarify purpose · a59f269b
      Duncan Coutts authored
      The ProgramDb in the ElaboratedSharedConfig actually only ever contains
      the programs configured by the compiler, and this is the way it will
      remain, so rename to clarify that usage.
      Config for other non-compiler programs will be handled differently. This
      makes sense because the compiler (and programs) have to be shared
      between all packages, while for non-compiler programs it's possible in
      principle to use different versions for different packages within a
      project. Thus it's not possible to have a single shared ProgramDb for
      all programs for all packages (other than for the compiler).
    • 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
    • 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
      Note that these options are not actually used yet, which is why this
      patch can be so small. Using them is next.
    • 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.
    • 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.
    • 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.
    • Duncan Coutts's avatar
    • 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/
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
  3. 08 Apr, 2016 9 commits