The refactor in f70fc980 solved an
inconsistency in `buildAndInstallUnpackedPackage`. Namely, before the
refactor, we didn't pass `hsSetupBuildArgs` to the build invocations,
and afterwards we did.

The result is that build targets of (legacy) package `B`, that a package
`A` depends on, are now passed to the ./Setup build invocation of
package `B` (e.g. `./Setup build lib:openapi3` rather than just `./Setup
build`).

This means we no longer /build always all targets of a legacy-package/
(for example, the lib, the testsuites and the executables).
Instead only the required target (just the lib) will be built.

However, despite now passing the build args to `./Setup build`, we
weren't passing the same arguments to the `./Setup copy` invocation.
Therefore, `./Setup copy` would also try to copy targets of the package
that weren't built, resulting in a failure.

This fixes that failure by correctly passing the build targets to the
`./Setup copy` invocation, just like we do for the `./Setup build` one.

Fixes #9640

See cabal-testsuite/README.md for a detailed description
of the new architecture.

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

Fixes #767.

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

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

A bit of a megapatch.  Here's what's in it:

* First, a few miscellaneous utility functions and reexports
  in Cabal.  I could have split these into a separate commit
  but I was too lazy to.

* Distribution.Client.Install got refactored:
  instead of using PackageFixedDeps, it uses IsUnit
  instead.  This is because we weren't using ComponentDeps
  in a nontrivial way; we just need some graph structure
  and IsNode (with UnitId keys) fulfills that. I also removed the
  invariant checking and error reporting because it was
  being annoying (we check the invariants already in
  SolverInstallPlan).

* Look at Distribution.Client.ProjectPlanning.Types.
  This contains the primary type change: ElaboratedConfiguredPackage
  is now EITHER a monolithic ElaboratedPackage, or a per-component
  ElaboratedComponent (it should get renamed but I didn't do that
  in this patch.)  These are what we're going to store in our
  plans: if a package we're building has a Setup script which supports
  per-component builds, we'll explode it into a component.  Otherwise
  we'll keep it as a package.  We'll see codepaths for both
  throughout.

* OK, so the expansion happens in ProjectPlanning, mostly in
  'elaborateAndExpandSolverPackage'.  You should review the
  package hash computation code closely.  When we can separate
  components, we compute a hash for each INDEPENDENTLY.  This
  is good: we get more sharing.

* We need to adjust the target resolution and pruning code
  in ProjectOrchestration and ProjectPlanning.  I did a dumb
  but easy idea: if a user mentions 'packagename' in a
  target name, I spray the PackageTarget on every
  possibly relevant IPID in buildTargets', and then pare
  it down later.

* And of course there's code in ProjectBuilding to actual
  do a configure and then build.

* We change the layout of build directories so that we can
  track each component separately.  While I was doing that,
  I also added compiler and platform information.

Custom doesn't work yet because I need to give them their own
separate component, and teach Cabal how to build them specially.

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