Instead of expressing the intention in terms of PackageTargets, it now
takes helper functions that select the components to use for a package
target or a component target. These helpers are given the set of
AvailableTargets and they can do error checking and return failures.

This allows the build,configure,haddock,repl implementations to have
their own behaviour and error checking and reporting for selecting
targets.

The full details of error reporting are not covered yet.

selectTargets would also prune to to the targets, and optionally prune
to dependencies only. These aspects are now pulled out into the callers
in the various Cmd{Build,Repl,etc} modules.

It will make more sense to do it this way once we're doing more explicit
error checking in the callers.

Previously the resolveUserBuildTargets would return a PackageName which
meant we would subsequently select all versions of that package that
occur in the project during target selection (resolveAndCheckTargets).
Using PackageId means we only pick one version (though in future we may
still need to disambiguate multiple instances, or targets from multiple
active profiles)

This is one major part of a new implementation of translating from high
level user intentions of what to build into the detail of what specific
components to build.

This part collects and summarises information on what component are
available as targets. Each available target one has enough status info
to determine if we can possibly select the target or if not why not.

This information will be used by each command (build, repl, test etc) to
select the specific targets that a user intention refers to (and to
provide them enough information to be able to produce reasonable error
messages).

Collecting and summarising this info is unfortunately non-trivial
because as part of install plan elaboration we omit components that
cannot be built but these are still components that users could try to
refer to, so we have to reconstruct the info about the omitted
components. It's plausible that we may want to revise the elaborated
install plan representation to make this easier.

Previously it took the specification for the targets to build in terms
of PackageTarget which is a high-ish level specification of which
components to build. It is high level in the sense that it says things
like BuildDefaultComponents which still have to be elaborated into the
specific components.

This elaboration from the higher level intention of what to build into
what components to build specifically has to vary between different
commands (build, repl, run, test, bench) and it can also fail. These
features make it not a good fit to do within plan pruning. Instead it
is better to have plan pruning take the lower level specification of
what to build in terms of components and to do the conversion of high
level to low level separately. That will allow us to do it differently
for different commands and deal with failures better.

This patch does one step: it changes pruneInstallPlanToTargets from
taking [PackageTarget] to [ComponentTarget] and as an intermediate step
in refactoring it converts the existing elaboratePackageTargets code to
convert from the [PackageTarget] to [ComponentTarget] which is then used
by the calling code in ProjectOrchestration. The next step will be to
replace the elaboratePackageTargets with something more flexible and
that can handle errors better.

And push compatSubComponentTargets inside nubComponentTargets. The
motivation for this is we'll be exporting nubComponentTargets and using
it from the ProjectOrchestration as part of revised target handling.

The pruneInstallPlanToTargets function had two main passes. Split the
first pass into two passes. This simplifies things a bit and helps
clarify the fact that setting the root targets is something we do prior
to taking the dep closure.

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

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

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

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

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

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

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

The strategy is to save an 01-index.timestamp file that remembers
what --index-state the user requested during cabal update.
Subsequently, we use that index state if no more precise
index state was specified (via the flag or a project config.)

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

Ben Gamari authored 8 years ago and Mikhail Glushenkov committed 8 years ago

The former has been deprecated for quite some time.

(cherry picked from commit e4c36b9d)

kristenk authored 8 years ago and Mikhail Glushenkov committed 8 years ago

[ci skip]

kristenk authored 8 years ago and Mikhail Glushenkov committed 8 years ago

I added a function, 'debugAssert', that wraps 'assert' and only calls it when
the build flag 'debug-assertions' is enabled.  The flag defaults to false. I
only replaced one call to 'assert' so far (in Distribution.Solver.Modular.Linking)
in order to resolve #4258.

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

- Setup the ssh key for cabal-website deploy right before we use
  it, so it doesn't get clobbered by our pushbot deploy script.
  Furthermore, umask the key to 600, so that we can override it.

- Add some more helpful information to the Pushbot commit messages,
  including what branch/PR the build was for, and a link to the
  relevant GitHub page.

- Have Travis spoof the author and email of the original committer,
  so that Travis sends the build notification message to the right place.

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

[ci skip]

(cherry picked from commit 19c278fe)

Ben Gamari authored 8 years ago and Mikhail Glushenkov committed 8 years ago

(cherry picked from commit 00461cb6)

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

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

Mikhail Glushenkov authored 8 years ago and Edward Z. Yang committed 8 years ago

Failure introduced in 9098fac6.

kristenk authored 8 years ago and Mikhail Glushenkov committed 8 years ago

Tests can now declare flags before using them, in order to specify non-default
values for the fields in 'D.Types.GenericPackageDescription.Flag'.

kristenk authored 8 years ago and Mikhail Glushenkov committed 8 years ago

This fixes #4299. The change gives the dependency solver the flexibility to link
dependencies when the user has only set a manual flag on one of them.
Previously, the solver would force the constrained dependency to have the
flag value from the constraint and force the unconstrained dependency to have
the default flag value. In cases where the single instance restriction required
the dependencies to be linked, the solver couldn't find a solution.

Qualified constraints can still be used to force different dependencies on a
package to use different flag values. For example,
"--constraint 'pkg +flag' --constraint 'pkg2:setup.pkg -flag'" turns the flag on
for the top-level dependency and off for the setup dependency.

I also stored flag default values in the search tree to simplify the code.

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

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

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

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

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

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

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

- We switched to using regex-tdfa, as regex-posix is buggy on Windows.

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

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

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

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

In general, the test suite will not have any servers configured
so this warning is not very useful.

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

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

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