Allow automatic resolving of conditionals on more than just build-depends

[bos]

(Imported from Trac #342, reported by @dcoutts on 2008-08-25)

We have several classes of dependency that we can express in .cabal files. The most obvious is other Haskell packages via the build-depends field. The others are:

• C libs (extra-libraries)
• C headers (includes)
• other build tools (build-tools)
• pkg-config packages (pkgconfig-depends)
• MacOS X frameworks (frameworks)

And we may end up with more, like Windows assemblies.

If we know (by domain-specific means) what dependencies are available then
we should be able to automatically resolve flag conditions that depend on them.

So each one is it's own namespace and they have different representations of keys. Most use a name and some a version too.

Currently finalizePackageDescription takes a Maybe (PackageSet pkg) as a way of testing if deps are available. We should generalise this to a dep testing function (which is essentially what finalizePackageDescription turns it into internally) on a type that has alternatives for each of the dependency namespaces. If we only had to generalise it for package constraints we might go for Dependency -> [PackageId] but how should we do it when we have multiple namespaces and some require version constraints and others do not.

[bos]

(Imported comment by @dcoutts on 2008-08-25)

See related: #227 and #262

Oh, also language extensions are a dependency and one we can check for since we know if the compiler we intend to use supports them.

[bos]

(Imported comment by @nominolo on 2008-08-25)

From a discussion on #ghc we think the following needs to be done:

• resolveWithFlags is, in principle, agnostic to the kind of dependencies. It works basically as follows:
  1. pick a flag assignment
  2. determine all dependencies
  3. combine duplicate dependencies
  4. call the dependency checking function to find out if the dependencies can be satisfied

• ATM, step 3 above is too specific to package dependencies. We should generalise the DependencyMap datastructure to work for other kinds of dependencies. The semantics should still be that multiple dependencies on the same package/framework/etc. should be combined into one that satisfies both. The best place to implement this probably is inside a Monoid instance for a set of dependencies.

[bos]

(Imported comment by @kowey on 2008-08-27)

As requested by Duncan, I'm noting here an example of how this would be used by a large application.

To support the widest user base possible, darcs allows the user to use either libcurl, libwww or the HTTP package for fetching files. We also have logic such as "if the version of libcurl < 7.19, do not compile in any http support; if the version is > 7.19, but < 7.19.1, compile in HTTP pipelining support, but don't enable it because pipelining support in that version is buggy behind proxy servers; otherwise if libcurl is really new, enable HTTP pipelining by support"

This kind of logic we normally store in an autoconf test, but it would be nice if cabal could somehow support it. At the moment, our cabal file defaults to using curl, and disables HTTP pipelining support altogether. The user has to specify -f curl-pipelining to enable it.

[bos]

(Imported comment by @dcoutts on 2008-11-25)

Note also cabal-version is another kind of dependency, much like build-depends. This has been bothering darcs users.

See also #227.