Build system idea

[Iavor Diatchki]

Hello,

On Thu, Sep 4, 2008 at 1:30 PM, Duncan Coutts
<duncan.coutts at worc.ox.ac.uk> 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