GitLab

cabal-install: make user config optional if possible

Fixes #3494.

Add a goal order parameter to the dependency solver

Update stack.yaml

Fix issue 3460: avoid concurrent package db creation

Instead initialise all the ones we'll need in advance of building any
packages. The alternative would have been to use a lock, but there's no
particular advantage in trying to delay initialisation and avoiding
locks keeps things simpler.

This should fix #3460

Another similar issue was fixed by 1acc00f8 which serialised the
registration of packages in the local inplace package db, avoiding
lost updates (which could previously be observed in test case T3460).

Edward Z. Yang authored Jun 06, 2016 and Duncan Coutts committed Jun 26, 2016

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

New freeze command

This is ok, but not perfect since freezing is now more tricky with setup
deps. See https://github.com/haskell/cabal/issues/3502

Code to write it and to pick it up by default when reading the
cabal.project file.

There are various related properties here like packages that are going
to be built locally inplace rather than added to the store, but
sometimes we need to know if a package was originally specified by the
cabal.project file (explicitly or implicitly).

It takes a solver plan, makes an "elaborated plan" with nix style hashes
but still of mostly source package and then does an improvement phase to
make a plan with pre-existing packages from the store.

Previously it only returned the improved plan, but for some things it's
also useful to see the original elaborated plan with the source
packages. In partciular it will be useful for plan.json status output.
It will also be needed for the freeze command to be able to get at the
flag choices, since this info is not preserved in installed packages.

byorgey authored Jun 17, 2016 and Mikhail Glushenkov committed Jun 23, 2016

Only those modules found in a directory in hs-source-dirs will be added
to exposed-modules.  If a directory 'src' is found it will be used as
hs-source-dirs (note in this case any .hs files in the root directory
will NOT be added to exposed-modules).  If any directories are specified
on the command line with --source-dir, they will be used.  If no
directories are specified on the command line and there is no directory
named src, the root directory will be used.

Fixes #3484.

Change install lock to just a registration lock

Exit with non-0 code when build fails

Fixes issue #3495

This also adds a stub where we can add more detailed failure reporting,
but this starts with nothing more than the exit code.

Unlike the existing "cabal install" failure reporting, we don't need or
want "build" failure reporting to be quite so noisy in common cases like
the one local package failing to build, since ghc reports its own errors
and there's enough context to see what's going on.

Allowing parallel installation of files, just serialising the actual
registration. Also previously only store package installs were
serialised but we also need to serialise registration of packages in the
local inplace package db.

For ghc-8 fixes.

Should fix things on Windows in secure mode.

travis-script.sh: use shell arith expansion

Fix typo and trailing whitespace from 11650b26

Stop installing as soon as possible after a build failure

Instead of spawning expr we can use sh arithmetic expansion.

The parallel JobControl now has a built-in maximum job limit, so the
separate build JobLimit is unnecessary. The separate fetch JobLimit
is still useful.

This actually only tests the new-build side of things, but the code in
both cases is essentially identical. It also only tests the serial
JobControl not the parallel JobControl. It may be sensible to have a
specific unit test for the two JobControl implementations.

Including cancelling.

For both install and new-build.

Add a keepGoing :: Bool arg to control whether to keep going after a
build failure or whether to try and stop as soon as possible.

This makes use of the new JobControl interface to try cancelling
outstanding jobs and also for checking if there are jobs in progress.

For now the call sites are hard coded to use keepGoing = False.

The motivation here is to support an install mode where we stop as soon
as possible after one package fails, rather than going on as far as
possible with other packages.

To properly support this we need to be able to cancel jobs that have
been submitted but that have not yet been started. This is easy for the
serial JobControl but requires re-implementing the paralle JobControl.

In the previous impl we simply fork a thread immediately for each job
(and use a JobLimit externally to limit parallelim). The problem with
that is that all submitted jobs are actually executing, so there's no
way to cancel jobs that have not started yet (there are none). Combined
with the executeInstallPlan behaviour of exposing the maximum possible
paralleism this means that there can be a lot of jobs in progress
(though most waiting on the JobLimit), and none of them can be sanely
cancelled.

So in this impl we have a built-in maximum parallelism, so we're
executing at most that many jobs at once, while all others are waiting
to be executed. The ones that are waiting can be cancelled.

Because it's unspecified how many jobs can be cancelled, users can no
longer rely on counting the number of outstanding jobs so we add a new
method to check if there are any jobs remaining.

Subsequent patches will add tests and make use of these new features to
stop the install process as soon as possible after a failure, with a
new --keep-going flag to get the existing behaviour.