multiple cabal files in one directory?
aslatter at gmail.com
Sat Jan 8 05:04:26 CET 2011
On Fri, Jan 7, 2011 at 9:41 PM, <kahl at cas.mcmaster.ca> wrote:
> On Sat, Jan 08, 2011 at 12:38:30AM +0100, Henning Thielemann wrote:
>> On Fri, 7 Jan 2011, Kathleen Fisher wrote:
>> > Is it possible to have a directory with multiple cabal files, telling
>> > cabal which file to use for a given install request by passing in a
>> > flag, say something like:
>> >> cabal install -f pads.cabal
>> > or
>> >> cabal install -f forest.cabal
>> > In other words, something like the -f option in make.
>> > I looked through the cabal documentation, but didn't see an option for
>> > specifying the cabal file to use. Did I just fail to see the proper
>> > flag? or does it not exist?
>> I think it does not exist.
>> > If it doesn't, is that just because it
>> > hasn't been implemented, or is there a Good Reason?
>> If you tell what you are intending, then we can certainly find a solution
>> using existing Cabal features.
> My use case would be the following: I have a large library,
> which I want to split into several cabal packages.
> However, I would like to keep the whole library in a single
> hierarchical module directory structure,
> so when I decide to move some module from one package to another,
> I only have to move a line from one .cabal file to another,
> and not move any files.
> That would allow me to focus on the hierarchical module collection,
> and keep that completely independent of the package hierarchy.
> It is no fun to have eight sparsely populated directory trees
> with closely related files spread all over the place,
> instead of side by side where they sit in the module hierarchy.
> (My concern is not with cabal-install, just with .cabal files for
> package definition, and therefore also with Setup:
> I'd probably need to say something like:
> ./Setup -f forest.cabal configure -p --prefix=....
Even if that worked in Cabal, you would run into other problems -
taking a module out of a package description file doesn't stop GHC
from using it during compilation if it can find it, but it does stop
GHC from linking it. So you'd end up with lots of fun linker errors.
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries