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. Building wxHaskell (somewhat simplified) consists of the following steps: 1) Build wxc, a library which provides C callable functions for the C++ methods in wxWidgets. This is really a C project, and I don't think cabal is the appropriate tool. I have a makefile for this. 2) Build wxdirect, an automated FFI generator. This is pure Haskell. I have a cabal build for this. 3) Build wxcore library. This is a low-level Haskell wrapper around the wxc library which is essentially autogenerated using wxdirect. I have a cabal build for this. 4) Build wx library. This is a higher level Haskell library which depends on wxcore. I have a cabal build for this. The problem is that I have currently put the three cabal builds in separate directories, which makes the whole thing rather messy. Is there some way to specify the basic dependencies that: wx depends on wxcore wxcore depends on running wxdirect on some set of files wxdirect tool (an executable) needs to be built first. It would seem to me like this is probably a fairly common pattern in any project which wraps a substantial external library, as the approach is: automatically wrap the C API to give a low level (basically imperative) Haskell API; wrap the low level API in something more 'Haskellish'. I'm looking for a suggested approach. I could roll my own, but it sounds like there is a generic pattern here, so I'd rather (if I have to) write something others can also use (or, better, use something others have already done ;-) Regards Jeremy On 09/01/07, Duncan Coutts wrote:

On Mon, 2007-01-08 at 15:20 -0800, Ashley Yakeley wrote:

...

Is there a way to tell cabal to pick a particular .cabal file when there are several in the current directory?

Not at the moment, no.

Duncan

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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

On Tue, Jan 09, 2007 at 01:12:56PM +0100, Henning Thielemann wrote:

On Mon, 8 Jan 2007, Ashley Yakeley wrote:

...

Is there a way to tell cabal to pick a particular .cabal file when there are several in the current directory?

I had the same question earlier. If multiple .cabal files are supported, there must also be multiple .installed-pkg-config and .setup-config files.

I've always seen this as a major issue with the design of Cabal. Why should there have to be a single file named XXX.cabal when XXX doesn't actually have a meaning to the Cabal system? If there can only be one such file, then it should be called Cabalfile or somesuch. On the other hand, if users are going to be asked to pick a name for their Cabal file, then multiple files should be allowed. The answer I've always received is that "someday multiple cabal files will be allowed". However, if that is the case (and I think it should be) then I think it would be better to start planning for such use as early as possible. Otherwise people start depending on things like .setup-config which may change in new versions of Cabal. And I imagine there are tools which currently depend on having a single Cabal-file in a directory, which will have to be changed as well. Although I don't have time to devote to this problem, anyone who does will have my special gratitude. Best wishes, Frederik -- http://ofb.net/~frederik/