Support building source trees with many packages

[bos]

(Imported from Trac #931, reported by @tibbe on 2012-03-12)

A not uncommon use case is building a package against a set of dependencies that exist in (unreleased) source form. For example, given two packages:

$ ls
hashable
unordered-containers

I'd like to be able to

$ cd unordered-containers
cabal build --root=..

Cabal should then recursively traverse directories from --root, looking for .cabal files to use when fulfilling dependencies (i.e. in this case it'd find hashable.) Those dependencies should also be marked as preferred to any Hackage versions of the package with the same version number.

It'd also be convenient to add several --root flags, so one can specify specific packages to use in source form (without using e.g. the user's complete ~/src directory.)

$ cd unordered-containers
cabal build --root=../hashable --root=../text

[bos]

(Imported comment by @kosmikus on 2012-03-12)

Also see #734, #409.

[bos]

(Imported comment by @dcoutts on 2012-03-12)

Note that a closely related existing feature is the ability to do:

cd unordered-containers
cabal install ./ ../hashable

What is missing is the ability to do just a configure or build without doing the full install.

Note that #734 is about multiple .cabal files in the same dir, which isn't what this ticket is requesting. #409 is closer.

I'm not sure I like the proposed UI, but the general idea is right. It should be easy to define local environments for finding packages (either local build trees, local or remote tarballs). My thoughts on this are that we need an extended package index format which allows links to local build trees and tarballs, then we need a UI to create and manipulate that environment. This approach is much more similar to cabal-dev which lets you add packages into a local index, but extended so that instead of just taking snapshots of build trees as tarballs we can link directly to local build trees.

[quasicomputational]

This is fixed! cabal.project files are a thing.