GitLab

Split things up a little so the generic async fetch can live with the
other fetch utils. This also makes it easier to test.

Change the exception handling so that any exception in fetching is
propagated when collecting the fetch result.

As a result of the previous InstallPlan refactoring, we can now use the
non-serialisable BuildFailure type from D.C.Types which uses
SomeException, where previously we had to use a copy of that type that
used String for the errors.

So now there's no longer any need to have a separate set of types for
BuildResult, BuildResults, BuildSuccess or BuildFailure. There was a
minor difference in the structure of the BuildSuccess, where in the new
build code we need to be able to produce the InstalledPackageInfo at a
different point from the rest of the info in the BuildSuccess. This can
be kept local to the ProjecBuilding module, but accounts for the
somewhat larger number of changes in that module.

Make internal/self-exect setup methods more chatty.

Installplan refactor

Add an IsNode instance for Either.

LocalBuildInfo: combine profiling settings, track program coverage

Edward Z. Yang authored Jul 24, 2016 and Duncan Coutts committed Jul 25, 2016

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

These were used previously for the Installed and Failed package states,
but these states are now gone.

Importantly this now means that we can have a serialisable InstallPlan
without the failure types having to be serialisable. This means we can
use things like SomeException which is not serialisable. Since the
traversal is done separately, the result of the traversal contains the
failure values, but this result set does not have to be serialised.

We now just have the initial states, PreExisting and Configured. The
Processing, Installed and Failed states are gone. We now do traversals
separately from the InstallPlan, so we no longer need these states.

Rename from prime' versions to the normal names, now that the old ones
have been removed.

There were two uses other than excuteInstallPlan. The new ready impl can
be used in both these cases, allowing the old one to be removed.

These were the primitives used by executeInstallPlan to change the
package states to Processing, Installed, Failed etc.

The 'ready' is still used in a couple other places, so those need to be
modified before the old 'ready' can be removed.

Redefine the local executeInstallPlan util in terms of
InstallPlan.execute. Of course now executeInstallPlan returns
BuildResults instead of an upated InstallPlan. This requires changes in
all the code that looks at the result of the build execution, including
console error reporting, build reports, symlinks etc.

Eliminate the local executeInstallPlan. The main change is that the new
execute returns BuildResults instead of an upated InstallPlan. This has
a few knock-on conseuqnces for the code that looks at the result of the
build execution.

Currently we don't actually do that much with the results in the
new-build code path (though we should) so there's less disruption than
one might imagine. The biggest change is in the integration tests which
do inspect the execution result to check things worked or didn't work as
expected.

The equivalent change for the old build code path will be more
disruptive since it does a lot of stuff with the execution results.

This is intended to replace a couple existing executeInstallPlan
implementations.

The tests check that execute visits packages in reverse topological
order, for both serial and parallel job control. There's also a check
that serial execute and executionOrder use exactly the same order.

Delete two different ugly versions of linearizeInstallPlan. Yay.

This is a replacement for the existing linearizeInstallPlan utils.
It uses the new separate traversal approach.

Currently the way to traverse/execute an InstallPlan involves using the
InstallPlan itself as the processing state.

This adds a new Processing type and associated operations to help write
InstallPlan traversals that are separate from the InstallPlan itself.

Needed for some new InstallPlan functions

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

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

The status of Haskell program coverage is recorded in
LocalBuildInfo. Program coverage is disabled during configure if the
compiler does not support it.

doc: Add brief description of setup-depends

The main thing this adds is infrastructure for generating random
InstallPlans (which is not totally trivial given their structure).

Implement --cabal-file, allows multiple Cabal files in directory

This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see #3552.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Refactor LocalBuildInfo interface.

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

The big change here is that most of the functions in
Distribution.Types.HookedBuildInfo have to take a
PackageDescription explicitly.  I hate the new type,
so I primed these new functions, and added functions
which use 'localPkgDescr'.  Presently those have WARNINGs
attached to them so people don't accidentally use them;
once we fix 'HookedBuildInfo' we can change this.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

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

This is an omnibus patch, with the overall goal of making
LocalBuildInfo Great Again.  The essential ideas:

* New type 'TargetInfo' which bundles together 'ComponentLocalBuildInfo'
  and 'Component'.  Eventually, it will also record file paths / module
  targets.  This data structure is basically what you want; a lot of
  old Cabal code did lots of gyrations converting from
  'ComponentLocalBuildInfo' to 'Component' and vice versa, now
  it's all centralized.

* The "new" API for 'LocalBuildInfo' is in
  "Distribution.Types.LocalBuildInfo".  The general principle
  is, where we previous dealt in 'ComponentLocalBuildInfo',
  we now deal in 'TargetInfo'.  There are shockingly few
  functions we need!

* I've restored 'componentsConfigs' to its Cabal 1.24 signature
  for BC.

* I killed a number of unused functions from "Distribution.Simple.LocalBuildInfo":
  'getLocalComponent', 'maybeGetDefaultLibraryLocalBuildInfo',
  'maybeGetComponentLocalBuildInfo', 'checkComponentsCyclic' and
  'enabledComponents'.  For each I checked on Hackage that they were
  not used.

* 'getComponentLocalBuildInfo', 'withComponentsInBuildOrder' and
  'componentsInBuildOrder' are deprecated to encourage people
  to instead use the 'TargetInfo's to finger which components
  they want built.

* 'ComponentLocalBuildInfo' now stores internally the computed
  'componentInternalDeps', so that 'LocalBuildInfo' can simply store
  a graph of 'ComponentLocalBuildInfo'.

* The code in Configure has been streamlined to use our new Graph
  data type to great success.

* The type of 'runTest' changed to take a 'ComponentLocalBuildInfo',
  bringing it more in line with everything else.

* New function 'readTargetInfos' which combines 'readBuildTargets'
  and 'checkBuildTargets', which is what you really wanted anyway.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Restore autogenModulesDir to BC-compatible signature

autogenModulesDir's proper name is autogenPackageModulesDir, and
it's an autogenerated file directory that applies to ALL
components in the package.  It lives in 'global-autogen'.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>