This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 04 Mar, 2016 1 commit
  2. 20 Feb, 2016 1 commit
  3. 19 Feb, 2016 2 commits
  4. 18 Feb, 2016 1 commit
  5. 01 Feb, 2016 1 commit
    • Duncan Coutts's avatar
      Solver: support setup deps for --allow-newer · 2119e63a
      Duncan Coutts authored
      The "allow newer" feature works by transforming the package descriptions
      to adjust the dependencies on certain packages. This transformation was
      not being applied to the dependencies of custom setup scripts.
      2119e63a
  6. 29 Jan, 2016 2 commits
    • Duncan Coutts's avatar
      Solver feature: default setup dependencies · c7606c93
      Duncan Coutts authored
      Newer packages can have explicit dependencies for their Setup.hs
      scripts. This feature allows us to supply setup dependencies for
      packages that do not specify explicit dependencies. This makes it
      possible to implement policies like having older custom Setup.hs scripts
      depend on an older Cabal lib (e.g. adding a default dep on Cabal < 1.23)
      
      The nix-local-build branch implements this policy and it goes further
      and tracks all setup deps so that no "ambient" packages are ever used.
      c7606c93
    • Duncan Coutts's avatar
      Solver feature: soft prefs for enabling testsuites/benchmarks · 114b3810
      Duncan Coutts authored
      The solver has the concept of hard constraints and soft preferences.
      For versions we have both constraints and preferences. We also have
      soft preferences available for whether we'd like installed instanes
      or not.
      
      We also have hard constraints for enabling "optional stanzas" (ie test
      suites or benchmarks). This patch adds soft preferences for the same.
      That is it lets us express the desire to please try enabling test suites
      and/or benchmarks, but allow them to be disabled if a solution cannot
      easily be found with them enabled.
      
      The implementation is very straightforward and not at all scary. :-)
      The original design was discussed with kosmikus and it has seen
      extensive testing in the nix-local-build branch.
      
      Optional stanzas in the solver are treated very much like flags, and so
      we can follow the pattern of a similar feature for flags for this
      feature for optional stanzas. For both flags and optional stanzas the
      solver has a node with up to two choices: True & False, corresponding to
      enable and disable. Various policies can be expressed by reordering
      these two choices or replacing one or other branch with failure. For
      example we can force enabling by replacing the False choice with
      failure. Flag default values are implemented by reordering the True and
      False branches (since the solver will try the first branch first).
      
      So this preference is implemented simply by reordering to put the True
      branch first (keeping both branches). That way the solver will try the
      enable branch first and backtrack to the False branch (which imposes no
      constraints). It integrates smoothly with stanza constraints, which
      adjusts the False branch to be a failure, thereby forcing the True
      branch (or further failure).
      
      The top down solver is simply adjusted for the types, the feature is not
      implemented there.
      
      The feature is not yet used. It's not intended to have any command line
      flag, but to express future policies.
      114b3810
  7. 16 Jan, 2016 1 commit
    • 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
  8. 26 Dec, 2015 1 commit
  9. 01 Dec, 2015 1 commit
  10. 09 Oct, 2015 1 commit
    • Edward Z. Yang's avatar
      Implement ComponentId, replacing PackageKey and InstalledPackageId. · b083151f
      Edward Z. Yang authored
      
      
      Today in Cabal, when you build and install a package, it is
      uniquely identified using an InstalledPackageId which is computed
      using the ABI hash of the library that was installed.  There
      are few problems with doing it this way:
      
          - In a Nix-like world, we should instead uniquely identify
            build products by some sort of hash on the inputs to the
            compilation (source files, dependencies, flags).  The ABI
            hash doesn't capture any of this!
      
          - An InstalledPackageId suggests that we can uniquely identify
            build products by hashing the source and dependencies of
            a package as a whole.  But Cabal packages contain many components:
            a library, test suite, executables, etc.  Currently, when
            we say InstalledPackageId, we are really just talking about
            the dependencies of the library; however, this is unacceptable
            if a Cabal package can install multiple libraries; we need
            different identifiers for each.
      
          - We've also needed to compute another ID, which we've called
            the "package key", which is to be used for linker symbols
            and type equality GHC-side.  It is confusing what the distinction
            between this ID and InstalledPackageIds are; the main reason
            we needed another ID was because the package key was needed
            prior to compilation, whereas the ABI hash was only available
            afterwards.
      
      This patch replaces InstalledPackageId and PackageKey with a
      new identifier called ComponentId, which has the following
      properties:
      
          - It is computed per-component, and consists of a package
            name, package version, hash of the ComponentIds
            of the dependencies it is built against, and the name
            of the component.  For example, "foo-0.1-abcdef" continues
            to identify the library of package foo-0.1, but
            "foo-0.1-123455-foo.exe" would identify the executable,
            and "foo-0.1-abcdef-bar" would identify a private sub-library
            named bar.
      
          - It is passed to GHC to be used for linker symbols and
            type equality.  So as far as GHC is concerned, this is
            the end-all be-all identifier.
      
          - Cabal the library has a simple, default routine for computing
            a ComponentId which DOES NOT hash source code;
            in a later patch Duncan is working on, cabal-install can
            specify a more detailed ComponentId for a package
            to be built with.
      
      Here are some knock-on effects:
      
          - 'id' is a ComponentId
      
          - 'depends' is now a list of ComponentIds
      
          - New 'abi' field to record what the ABI of a unit is (as it is no longer
            computed by looking at the output of ghc --abi-hash).
      
          - The 'HasInstalledPackageId' typeclass is renamed to
            'HasComponentId'.
      
          - GHC 7.10 has explicit compatibility handling with
            a 'compatPackageKey' (an 'ComponentId') which is
            in a compatible format.  The value of this is read out
            from the 'key' field.
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      b083151f
  11. 31 Jul, 2015 3 commits
  12. 30 Jul, 2015 6 commits
  13. 07 Apr, 2015 1 commit
  14. 27 Mar, 2015 1 commit
    • Edsko de Vries's avatar
      Deal with independent goals in plan validation · d56e1d8a
      Edsko de Vries authored
      In particular, in the definition of dependencyInconsistencies.
      
      One slightly annoying thing is that in order to validate an install plan, we
      need to know if the goals are to be considered independent. This means we need
      to pass an additional Bool to a few functions; to limit the number of functions
      where this is necessary, also recorded whether or not goals are independent as
      part of the InstallPlan itself.
      d56e1d8a
  15. 10 Dec, 2014 1 commit
    • Luite Stegeman's avatar
      use CompilerInfo rather than CompilerId for resolving flags and · 7d91b773
      Luite Stegeman authored
      path templates.
      
      CompilerInfo contains more information about the compiler than
      CompilerId, which just stores the flavour and version. In particular,
      CompilerInfo knows an AbiTag, which can be used to tell binary
      incompatible results from the same compiler apart, and detailed
      information about supported languages and extensions.
      
      Some fields in CompilerInfo may be left unknown (Nothing). This can
      be used in the future to allow partially resolving configurations
      based on supported languages or extensions.
      7d91b773
  16. 03 Oct, 2014 2 commits
  17. 23 Sep, 2014 1 commit
  18. 27 Aug, 2014 2 commits
  19. 09 Jun, 2014 2 commits
    • Herbert Valerio Riedel's avatar
      Allow template-haskell to be upgradable again · ffd67e5e
      Herbert Valerio Riedel authored
      This partly reverts 65e9b88b
      which marked `template-haskell` non-upgradable. However, since are now
      able to fix-up wrong .cabal meta-data on Hackage, previous `template-haskell`
      releases have been augmented by proper version bounds so that it's now
      safe again to let the Cabal solver handle reinstalling `template-haskell`
      
      See also #1811, #667, #1761, and #1444
      
      (cherry picked from commit 65ae95c1 / #1934)
      ffd67e5e
    • Herbert Valerio Riedel's avatar
      Allow template-haskell to be upgradable again · 65ae95c1
      Herbert Valerio Riedel authored
      This partly reverts 65e9b88b
      which marked `template-haskell` non-upgradable. However, since are now
      able to fix-up wrong .cabal meta-data on Hackage, previous `template-haskell`
      releases have been augmented by proper version bounds so that it's now
      safe again to let the Cabal solver handle reinstalling `template-haskell`
      
      See also #1811, #667, #1761, and #1444
      65ae95c1
  20. 23 May, 2014 1 commit
    • Andres Löh's avatar
      Configurable strong/weak flags. · f950e8d7
      Andres Löh authored and tibbe's avatar tibbe committed
      This adds a mechanism in the modular solver to store whether a flag
      is "strong" or "weak". A weak flag is deferred during solving, a strong
      flag is not.
      
      By default, flags are now weak unless they're manual. This is a change
      in behaviour, but I think it's probably the better default, because many
      automatic flags are used to figure out what's on the system rather than
      to impose hard constraints.
      
      There's a new flag --strong-flags that restores the old behaviour. I do
      not think such a global flag is particularly useful, but it may be
      of interest to compare build plans between the new and old behaviour.
      
      With these preparations, it's easy to make the distinction between
      strong and weak flags more sophisticated. We can either add more
      heuristics as to when flags should be treated as strong or weak, or we
      can add syntax to .cabal files that allows package authors to specify
      explicitly how they intend a flag to behave.
      
      This is related to various cabal-install issues, e.g. #1831, #1864,
      and #1877.
      
      (cherry picked from commit 3dcddea4)
      
      Conflicts:
      	cabal-install/Distribution/Client/Dependency.hs
      f950e8d7
  21. 19 May, 2014 1 commit
    • Andres Löh's avatar
      Configurable strong/weak flags. · 3dcddea4
      Andres Löh authored
      This adds a mechanism in the modular solver to store whether a flag
      is "strong" or "weak". A weak flag is deferred during solving, a strong
      flag is not.
      
      By default, flags are now weak unless they're manual. This is a change
      in behaviour, but I think it's probably the better default, because many
      automatic flags are used to figure out what's on the system rather than
      to impose hard constraints.
      
      There's a new flag --strong-flags that restores the old behaviour. I do
      not think such a global flag is particularly useful, but it may be
      of interest to compare build plans between the new and old behaviour.
      
      With these preparations, it's easy to make the distinction between
      strong and weak flags more sophisticated. We can either add more
      heuristics as to when flags should be treated as strong or weak, or we
      can add syntax to .cabal files that allows package authors to specify
      explicitly how they intend a flag to behave.
      
      This is related to various cabal-install issues, e.g. #1831, #1864,
      and #1877.
      3dcddea4
  22. 23 Apr, 2014 2 commits
  23. 14 Apr, 2014 1 commit
  24. 10 Apr, 2014 2 commits
  25. 09 Apr, 2014 1 commit
  26. 06 Dec, 2013 1 commit