GitLab

The DEBUG_TRACETREE debugging feature of cabal-install
still had a call to 'showVersion' in it, which has been
removed by recent changes to 'Distribution.Version'.

Similiar to dabd9d98 which made
`PackageName` opaque, this makes `Distribution.Version.Version` opaque.

The most common version numbers occuring on Hackage are 3- and
4-part versions. This results in significant Heap overhead due to
`Data.Version`'s inefficient internal representation.

So like the `PackageName` commit, this commit is a preparatory commit to
pave the way for replacing `Version`'s internal representation by a
representation with a memory footprint which can be an order of
magnitude smaller.

Finally, this also adds a new functor-like convenience function

    alterVersion :: ([Int] -> [Int]) -> Version -> Version

for modifying the version number components.

When looking at heap-profiles of `cabal-install`, the `(:)` constructor
stands out as the most-allocated constructor on the heap.

Having to handle 10k+ package names contributes to the allocation
numbers, especially on 64bit archs where ASCII `String`s have a 24 byte
per character footprint.

This commit is a preparatory commit to pave the way for changing
`PackageName`'s internal representation to something like
`ShortByteString` (which is essentially a thin wrapper around primitive
`ByteArray#`s which themselves have have an overhead of 2 words + one
byte per ASCII character rounded up to nearest word) which would allow
to reduce the memory footprint by a full order of magnitude, as well as
reduce pointer chasing and GC overhead.

There is a bug in `cabal configure`'s invocation of the solver in
Distribution/Client/Configure.hs:

    standardInstallPolicy
        installedPkgIndex
        (SourcePackageDb mempty packagePrefs)
        [SpecificSourcePackage localPkg]

We can see that the solver is given an EMPTY source package database.
This is because we assume that everything you need from cabal configure
is taken from the installed package index.

But this is NOT true for executables, which never have an entry in the
installed package index. So we SHOULD NOT solve for
executables in the legacy codepath, since there isn't anything useful we
can do with the info anyway.  This gets toggled using a new solver
parameter SolveExecutables.

I didn't bother with a test because this will be obsoleted by
nix-local-build.

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

The solver can handle duplicate targets by linking them together, but the log
is more complex, and the result is the same as if the targets were deduplicated
beforehand.

Duplicate targets can occur in a sandbox (issue #3203).

If we were generating Haddock for cabal-install (we're not
currently) these would cause errors.  Make them stop causing
errors.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

When solving, we now discard plans that would involve packages with a
pkgconfig-depends constraint which is not satisfiable with the current
set of installed packages (as listed by pkg-config --list-all).

This fixes https://github.com/haskell/cabal/issues/3016.

It is possible (in principle, although it should be basically impossible
in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to
execute for various reasons, in particular because N is too large, so
the command line becomes too long for the operating system limits.

If this happens, revert to the previous behavior of accepting any
install plan, regardless of any pkgconfig-depends constraints.

This change primarily does two things:

1. For `--reorder-goals`, we use a dedicated datatype `Degree`
   rather than an `Int` to compute the approximate branching
   degree. We map 0 and 1 to the same value. We then use a
   lazy ordering and a shortcutting minimum function to look
   for the "best" goal.

   The motivation here is that we do not want to spend
   unnecessary work. Following any goal that has 0 or 1 as degree
   cannot really be "wrong", so we should not look at any others
   and waste time.

   This will still not always make the use of `--reorder-goals`
   better than not using it, but it will reduce the overhead
   introduced by it.

2. We use partitioning rather than sorting for most of the other
   goal reordering heuristics that are active in all situations.
   I think this is slightly more straightforward and also slightly
   more efficient, whether `--reorder-goals` is used or not.

I have run some preliminary performance comparisons and they
seem to confirm that in both cases separately (with or without
`--reorder-goals`), these changes are a relative improvement
over the status quo. I will run additional tests before
merging this into master.

A number of small changes:

- Some comment typos fixed.
- The main function for cycle detection is now called
  `cycleDetectionPhase`, in analogy with all the other
  phases.

I've run a superficial performance test trying to install
all of Hackage on a clean db with ghc-7.10.3. This is not
likely to trigger any situations where cycle detection
actually kicks in, but it confirms in general that there is
no negative performance (or correctness) impact for the
common case.

I've also considered moving the cycle detection phase to
"earlier" in the solver, but after performance testing, decided
against it, and documented the decision and the reasons in
the code.

Missing parentheses caused the solver to skip preferring linked packages with
the use of --reorder-goals.

This commit refactors backjumping so that it uses the 'Progress' type instead of
separate references to a node's children and the conflict set calculated from
those children.

Every package now "depends" on all language extensions
(default-extensions and other-extensions) and language flavours
(default-language and other-languages) it declares in its cabal file.

During solving, we verify that the compiler we use actually
supports selected extensions and languages. This has to be done
during solving, because flag choices can influence the declared
extensions and languages being used.

There currently is no equivalent check performed on the generated
install plans. In general, cabal-install performs a sanity check
on the solver output, checking that the solver e.g. indeed includes
all the declared dependencies of a package. There is no such
double-checking for language extensions. This is not really
problematic, as all that this change does is to make the solver
more conservative rather than less. However, having a sanity check
available might ultimately be nice to have.

This commit adds the sources of constraints to debugging and error messages,
e.g., "main config file" or "command line flag".

Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10798002.

By chosing setup dependencies after regular dependencies we get more
opportunities for linking setup dependencies against regular dependencies.

This is implemented as a separate pass so that it can be understood
independently of the rest of the solver.

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)

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

Andres Löh authored May 19, 2014 and tibbe committed May 23, 2014

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