Hello,
On Thu, Sep 4, 2008 at 1:30 PM, Duncan Coutts
cabal-install: it does not work well with packages that have flags because it does not know what flags to use when building dependencies. Really, packages with conditionals are different packages in one cabal file.
Packages are not supposed to expose different APIs with different flags so I don't think that's right. Under that assumption cabal-install can in principle resolve everything fine. I'm not claiming the current resolution algorithm is very clever when it comes to picking flags (though it should always pick ones that give an overall valid solution) but there is certainly scope for a cleverer one. Also, the user can always specify what features they want, which is what systems like Gentoo do.
Do you have any specific test cases where the current algorithm is less than ideal? It'd be useful to report those for the next time someone hacks on the resolver.
The examples that I was thinking of arise when libraries can provide conditional functionality, depending on what is already installed on the system, a kind of "co-dependecy". For a concrete example, take a look at the JSON library that I wrote (I think that it is on hackage). It provides a number of different modules containing parsers written with different parser combinators: one that does not use a library, one that uses ReadP, and one that uses Parsec. The idea was that we do not want to force people to install a particular parser combinator library, instead, we provide compatibility with many different ones. Certainly, JSON does not require _all_ libraries to be installed, but the way the flags are at the moment, I think that that is what happens if you just use cabal-install. (The same sort of thing happens when a library provides instances for datatypes defined in different packages---these instances are often not required by the library, but are useful _if you have the other package installed_.) I guess, you could say that we structured the library wrong---perhaps we should have had a core package that only provides manual parsing (no external libraries required), and then have a separate packages for each of the parsers that use a different parsing combinator library. Conceptually, this might be better, but in practice it seems like a bit of a pain---each parser is a single module, but it would need a whole separate directory, with a separate cabal file, license, and a setup script, all of which would be almost copies of each other. Similarly, in the case of providing instances for datatypes from different packages, one would end up with a separate package for each set of instances, which would result in a proliferation of tiny packages. It seems that this problem should be solvable though... :-) (by the way, this has little to do with the GHC build system, so perhaps we should start a separate thread?) -Iavor