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

Fix typo in haddock comment

Stop recommending detailed-0.9, no one actually believes that.

This was overlooked in  a8a121ea

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

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

Fix #3319: Give proper CommandUI to the Nix-local build commands.

Set LC_ALL=C for integration-tests, partial workaround for #3326.

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

Give an explicit message when SIGSEGV happens.

Fixes #767.

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>

Fix #3335 by not passing build arguments if not supported.

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>

* Properly render both depends and exe-depends in components. (by @ezyang)
* Import ComponentDeps qualified to avoid clashes
* Make ComponentDeps.zip compatible with containers<0.5

- New "exe-depends" field
- Dropped "depends" when it's a package; you can use
  "components" to get the information

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

Actually we could probably do this a bit more properly with
UnitId in the Backpack patchset.

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

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

This fixes #220: new-build now builds, installs and adds executables to
PATH automatically if they show up in 'build-tools'.  However, there is
still more that could be done: the new behavior only applies to a
specific list of 'build-tools' (alex, happy, etc) which Cabal recognizes
out of the box.  The plan is to introduce a new 'tool-depends' field to
allow dependencies on other executables as well.

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

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

As requested by Duncan, the majority of fields that originally
lived in ElaboratedPackage now are moved to ElaboratedConfiguredPackage
under the prefix 'elab'.  Some code has gotten simpler as a result.

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>

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 causes strange output when we output the install plan.
Thanks @hvr for reporting.

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

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

Two big ideas:

    * @--dependency@ takes a ComponentId, not UnitId.
      I used to think it should be a UnitId but it is
      now clear that you want to finger the indefinite
      unit id, which can be uniquely identified with
      a ComponentId

    * When hashing for an InstalledPackageId in
      new-build, we should produce a ComponentId,
      not a UnitId.

While cleaning up the results, for any codepaths which we don't plan on
implementing Backpack (Distribution.Client.Install, I'm looking at you),
just coerce ComponentId into UnitIds as necessary.

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>

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>

The previous approach I took, though correct, was quite
confusing.  If I refactor InstallPlan to operate on a
per-component basis, then we'll automatically get support
for convenience libraries, which will ultimately cleaner.
(While we won't be able to get rid of support for whole
package installs, it will be safe to assume packages
using convenience libraries also support one-shot
configure.)

I didn't revert the support in cabal install; I'm not
planning on componentizing it.

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

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