* Add `cabal-version` 3.12

* Add test for #9331

- `cabal check`: Guard Paths_* behind `cabal-version: 3.12` or higher,
  “fail” and “succeed” tests.
- `cabal build`: Guard Paths_* behind `cabal-version: 3.12` or higher,
  “fail” test.

* Guard PackageInfo behind cabal-version ≥ 3.12

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

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

New output:

Error:
    Problem with module re-exports:
      - The module 'Asdf'
        is not exported by any suitable package.
        It occurs in neither the 'exposed-modules' of this package,
        nor any of its 'build-depends' dependencies.
    In the stanza 'library'
    In the inplace package 'Reexport2-1.0'

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>