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 ;-)
> 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.
> Libraries mailing list
> [hidden email] > http://www.haskell.org/mailman/listinfo/libraries >
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. We're really only just
past the early phase of Cabal development which was aimed at making
simple libs/progs easy to build.
So basically we need to discuss what we would like for larger projects
and come up with a design. We also need volunteers to implement
proposals (of course if these are one and the same then there's a good
incentive to keep things simple!) Either this mailing list or the
cabal-devel list is the appropriate place for such discussions.
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.
> 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).