GitLab

 - Existing test `InternalLibrary4` was deleted because it relied on the old
   behavior.

 - New tests added are:
    - InternalVersions/BuildDependsBad
    - InternalVersions/BuildDependsExtra
    - InternalVersions/BuildToolsBad
    - InternalVersions/BuildToolsExtra
    - InternalVersions/BuildToolDependsBad
    - InternalVersions/BuildToolDependsExtra
    - ToolDependsInternalMissing

Previously:

 - "build-depends" entries on internal libraries with an explicit version
   range are an error.

Now for all three of "build-tools", "tool-depends", and "build-depends":

 - Explicit versions ranges on internal components that are satisfied by
   the current package cause a warning.

 - Explicit version ranges on internal components are are not satisfied by
   the current package are an error.

And additionally for "tool-depends":

 - dependencies on a non-existent executable in the current package are an
   error.

A lack of ":exename" is susposed to indicate all exe components of the package,
but this complicates parsing so I'm punting for now: an explicit component name
is required.

The goal is to deemphasize calling it "new-build" and push "Nix-style Local
Builds" instead, as the former name only makes sense while the old system
is the default

Edward Z. Yang authored Jan 04, 2017 and Edward Z. Yang committed Jan 06, 2017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored Jan 02, 2017 and Edward Z. Yang committed Jan 06, 2017

The recorded build-depends should be consistent with the
extra metadata we created when dep-solving. No need to
overwrite.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored Jan 02, 2017 and Edward Z. Yang committed Jan 06, 2017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored Jan 02, 2017 and Edward Z. Yang committed Jan 06, 2017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored Jan 01, 2017 and Edward Z. Yang committed Jan 06, 2017

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

[ci skip]

[ci skip]

Add a comment to 'Distribution.Solver.Modular.Cycles.findCycles'.

[ci skip]

Edward Z. Yang authored Dec 27, 2016 and Edward Z. Yang committed Jan 02, 2017

A signature package is a package that contains only signatures but no
modules (equivalently, it is a package that has no provisions.)

Previously, we did not treat signature packages any differently from
normal packages, which, in particular, meant that when we instantiated a
package using a signature package, we also instantiated the signature
package.  This is actually pretty useless, because we never actually use
the instantiated signature (there's no code that actually gets compiled
in this case).

This patch treats signature packages specially, so that we don't
actually instantiate dependencies on them.  This means we have
to compile less packages when handling signatures.  Good!
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Nix integration improvements

Refine the fix for requiring Cabal > 1.20 for Setup.hs

Fixes #4196 

Mention that we allow `shell.nix` or `default.nix`, the same as
`nix-shell`.

cabal only cares if it is running in a Nix shell that was started by
another cabal process, so we should not read IN_NIX_SHELL; rather, we
read a cabal-specific variable for that purpose.

cabal2nix recently changed its generated expressions to read the
IN_NIX_SHELL environment variable. Now we need to set this variable when
calling nix-instantiate to produce the same result as calling nix-shell.

Duncan Coutts authored Oct 29, 2016 and Herbert Valerio Riedel committed Dec 31, 2016

Going along with the existing approach of using a constraint rather than
altering the deps of custom Setup.hs scripts, but make the constraint
only apply to Cabal instances that are dependencies of Setup.hs scripts
not all instances of Cabal.

Also rearrange things a little with a dedicated solver policy function
for adding a min dep on Cabal versions for setup scripts.

Edward Z. Yang authored Dec 30, 2016 and Edward Z. Yang committed Dec 30, 2016

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored Dec 27, 2016 and Edward Z. Yang committed Dec 27, 2016

There were a number of fields in 'LinkedComponent' which
were "too" flexible, in that they were fully determined by
other fields in the structure.  This refactor deletes those
fields and replaces them with functions that refer to the
fields directly.

I also introduce a new type, ComponentInclude, to take
the place of tuples which were used to represent includes
(mixins) in Backpack.

There's also more documentation for lots of bits.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

kristenk authored Dec 18, 2016 and Edward Z. Yang committed Dec 26, 2016

Previously, the solver only checked for cycles after it had already found a
solution. That reduced the number of times that it performed the check in the
common case where there were no cycles. However, when there was a cycle, the
solver could spend a lot of time searching subtrees that already had a cyclic
dependency and therefore could not lead to a solution. This is part of
https://github.com/haskell/cabal/issues/3824.

Changes in this commit:
- Store the reverse dependency map on all choice nodes in the search tree, so
  that 'detectCyclesPhase' can access it at every step.
- Check for cycles incrementally at every step. Any new cycle must contain the
  current package, so we just check whether the current package is reachable
  from its neighbors.
- If there is a cycle, we convert the map to a graph and find a strongly
  connected component, as before.
- Instead of using the whole strongly connected component as the conflict set,
  we select one cycle. Smaller conflict sets are better for backjumping.
- The incremental cycle detection automatically fixes a bug where the solver
  filtered out the message about cyclic dependencies when it summarized the full
  log. The bug occurred when the failure message was not immediately after the
  line where the solver chose one of the packages involved in the conflict. See
  https://github.com/haskell/cabal/issues/4154.

I tried several approaches and compared performance when solving for
packages with different numbers of dependencies. Here are the results. None of
these runs involved any cycles, so they should have only tested the overhead of
cycle checking. I turned off assertions when building cabal.

Index state: index-state(hackage.haskell.org) = 2016-12-03T17:22:05Z
GHC 8.0.1

Runtime in seconds:
Packages                    Search tree depth   Trials   master   This PR   #1      #2
yesod                       343                 3        2.00     2.00      2.13    2.02
yesod gi-glib leksah        744                 3        3.21     3.31      4.10    3.48
phooey                      66                  3        3.48     3.54      3.56    3.57
Stackage nightly snapshot   6791                1        186      193       357     191

Total memory usage in MB, with '+RTS -s':
Packages                                        Trials   master    This PR   #1     #2
yesod                                           1         189       188       188     198
yesod gi-glib leksah                            1         257       257       263     306
Stackage nightly snapshot                       1        1288      1338      1432   12699

#1 - Same as master, but with cycle checking (Data.Graph.stronglyConnComp) after
     every step.
#2 - Store dependencies in Distribution.Compat.Graph in the search tree, and
     check for cycles containing the current package at every step.

Fix #3440.

Fix provided by @mvkorpel.

[ci skip]

Mark `template-haskell` non-upgradable (again)

Depend on echo to fix #4128

65e9b88b made template-haskell non-upgradable

65ae95c1 made it upgradable again

...and this commit makes it non-upgradable again

While there may be a few cases when `template-haskell` can be
reinstalled, it's generally not advisable, and causes more harm than the
benefit in the few cases where we'd gain install-plan
flexibility (e.g. when only template-haskell's API is needed for
compile, but no actual TH evaluation takes place).

Closes #4098