Multiple .cabal Files

[Benjamin Franksen]

Duncan Coutts wrote:
> On Tue, 2007-01-09 at 10:35 +0000, Jeremy O'Donoghue wrote:
>> Oddly, I was about to ask almost exactly the same question.
>> 
>> The supplementary is:
>> 
>> I'm trying to convert wxHaskell to use a cabal based build system.
> 
> I have similar issues in trying to convert Gtk2Hs to use Cabal.
> 
> Basically Cabal doesn't yet have any coherent story for larger projects
> like Gtk2Hs, wxHaskell, GHC etc that are made up of many components and
> where some bits are needed to generate others. 

This is the sort of problems that make has been written for. Why re-invent
this special wheel? Make tracks /any/ sort of dependency, and it is very
good at that, you just need to give it all the necessary information i.e.
write the appropriate rules. I think a large part of the (generic) rules
needed for Haskell projects (including the large ones) could be written
once and for all and thus shared among projects. It is of course necessary
that these rules are completely configurable. Cabal could automatically
generate make-variable definitions from the .cabal file to be included
together with the generic rules; you could do this even for multiple
sub-projects (which nevertheless might share some sources and depend on one
another), using gnu-make's so called 'static pattern rules' (which are
formulated generically but apply only to a given list of targets). This
would mean that cabal becomes a generator for makefiles (or rather: make
include files). The project author will write the top-level makefile which
includes generic rules and cabal-generated variable definitions; for simple
projects it wouldn't be necessary to add anything; complex projects could
define extra rules (e.g. for special pre- or post-processing, for compiling
in code in foreign languages, or for tracking dependencies on things
external to the project).

Well, that's how I would do this, anyway.

Cheers
Ben