Hello, On Thu, Sep 4, 2008 at 1:30 PM, Duncan Coutts <[EMAIL PROTECTED]> wrote: >> 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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
