multiple cabal files in one directory?

newer
Library proposal: add a Location...

Kathleen Fisher

7 Jan 2011 7 Jan '11

5:48 p.m.

Hi, 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? If it doesn't, is that just because it hasn't been implemented, or is there a Good Reason? Thanks for any pointers and explanations! Kathleen

Show replies by date

Henning Thielemann

7 Jan 7 Jan

6:38 p.m.

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. So far I could describe the things I wanted using Cabal flags. For instance I can choose the Hs-Source-Dirs depending on a flag. I can switch on and off building of an executable and its dependencies using a flag. There are other things that could be done with flags, but should not be done, e.g. providing different APIs depending on a flag. http://www.haskell.org/haskellwiki/Cabal/Developer-FAQ

kahl＠cas.mcmaster.ca

10:41 p.m.

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=.... ) Wolfram

Antoine Latter

11:04 p.m.

On Fri, Jan 7, 2011 at 9:41 PM, 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. Antoine

...

Wolfram

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

Henning Thielemann

8 Jan 8 Jan

6:02 a.m.

...

On Fri, Jan 7, 2011 at 9:41 PM, wrote:

...
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.

I would make multiple directories, each with a Cabal file and then make a symbolic link to the source directory from each of these Cabal directories. However moving a module from one package to another one is a relatively large step, that breaks other packages and thus requires increasing the major version. I find it appropriate to move files for such a change. I also tried to manage several Cabal packages in one Darcs repository, e.g. the set of data-accessor packages. But I do not like that anymore since each sub-package has its own version and this does not work well with Darcs tags and the Darcs patch comments. On Fri, 7 Jan 2011, Antoine Latter wrote:

...

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.

That's unfortunately true. However I have written a small script, that 'sdist's a package, unpack it in /tmp/ and try to build it with Cabal there. I run this script before uploading to Hackage in order to check for missing files. Since I use Darcs it can easily happen that Darcs registration and Cabal registration of files are out of sync. If a file is added to Darcs repository but not to Cabal description, then the Darcs test, that builds the package will succeed because of GHC's --make feature. Maybe I should put my script into a Cabal package? Or try to integrate it into cabal-install?

Mario Blažević

10 Jan 10 Jan

12:46 p.m.

On 11-01-07 10:41 PM, kahl@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.

I had the same problem. My solution is as follows: I have a single directory infrastructure, which is also my single Darcs repository. Each sub-project is represented by foo.cabal.package file. During development I use a simple Makefile instead of Cabal, so I'm not sure if there would be any problem with it. When I want to release a sub-project, I create a symlink from foo.cabal.package to foo.cabal and execute cabal configure foo cabal build foo cabal sdist foo Before uploading to Hackage, I always unpack the foo.tar.gz in a different directory somewhere and install it using Cabal. This is necessary to test for any missing dependencies, because GHC will happily use a module file from the unified directory even if it's not specified in any package file. It also prevents me from releasing a package before releasing all its dependencies. The repository at http://code.haskell.org/SCC/, if something is not clear.

...

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=.... )

Wolfram

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

Peter Simons

5:23 a.m.

Hi Kathleen,

...

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 would like to have that feature in cabal, too, and at first glance it looks like a trivial thing to support. Unfortunately, it is not that easy. When we think of build instructions for Cabal, we tend to think of the "pkgname.cabal" file, but in fact that file is only half of it. The other half is "Setup.hs". Now, the vast majority of Haskell packages doesn't use Setup.hs, because building those packages is simple and the default settings hard-coded into Cabal get the job done just fine. There are packages, however, that ship custom written Setup.hs files that contains plenty of complex build know-how. So, instead of saying "cabal install -f pads.cabal", we would really have to say "cabal install -f1 pads.cabal -f2 Setup-pads.hs" or something like that. We *could* do that, of course, but obviously the makers of Cabal felt that it's easier to expect that separate packages live in separate directories, so that Setup.hs can be called "Setup.hs" in every package. Arguably, the choice to include the package name in the name of the Cabal file is inconsistent with that decision, and that inconsistency is confusing. If you look at a random package, then "foo.cabal" feels like a file that's specific to this package, but "Setup.hs" feels like a file that is generic. In fact, both are specific to this package, even though the name of the latter file doesn't make that clear. Take care, Peter

Ivan Lazar Miljenovic

5:47 a.m.

On 10 January 2011 20:23, Peter Simons wrote:

...

Now, the vast majority of Haskell packages doesn't use Setup.hs, because building those packages is simple and the default settings hard-coded into Cabal get the job done just fine. There are packages, however, that ship custom written Setup.hs files that contains plenty of complex build know-how.

As far as I'm aware, Setup.hs is still required/recommended: not _everyone_ uses cabal-install... Cabal itself still uses Setup.[l]hs; how else would you do "runhaskell Setup.hs configure", etc.? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Peter Simons

6:08 a.m.

Hi Ivan,

...

...
Now, the vast majority of Haskell packages doesn't use Setup.hs [...].

As far as I'm aware, Setup.hs is still required/recommended [...].

you are right, of course. I expressed myself poorly, and I am sorry about that. What I meant to say is that the majority of Haskell packages doesn't add any custom code to Setup.hs. Rather, these packages ship the standard version of that file, which typically looks like this: | module Main (main) where | | import Distribution.Simple | | main :: IO () | main = defaultMain Now, since the majority of packages ship that file, it may look like Setup.hs is a generic standard component that looks the same in *all* packages. However, there are packages that ship Setup.hs files that look very different. The "gtk" package is an impressive example for that.

...

Cabal itself still uses Setup.[l]hs [...].

Yes, that is true. Cabal must use the Setup.hs file, because that file is actually the main build driver for the package. The know-how encoded in that file determines how the package is built. I hope this clarifies the issue. Take care, Peter

Henning Thielemann

5:22 p.m.

Peter Simons schrieb:

...

Arguably, the choice to include the package name in the name of the Cabal file is inconsistent with that decision, and that inconsistency is confusing.

...

If you look at a random package, then "foo.cabal" feels like a file

Actually, the name does not have to be pkgname.cabal. You can choose any name with extension .cabal. Cabal complains about multiple files with that extension. So you could in principle call it description.cabal consistently in all your packages. that's specific to

...

this package, but "Setup.hs" feels like a file that is generic. In fact, both are specific to this package, even though the name of the latter file doesn't make that clear.

Duncan Coutts

6:16 p.m.

On 10 January 2011 22:22, Henning Thielemann wrote:

...

Peter Simons schrieb:

...
Arguably, the choice to include the package name in the name of the Cabal file is inconsistent with that decision, and that inconsistency is confusing.

Actually, the name does not have to be pkgname.cabal. You can choose any name with extension .cabal. Cabal complains about multiple files with that extension. So you could in principle call it description.cabal consistently in all your packages.

That's true, though I don't think I'd recommend it. The current convention of <pkgname>.cabal is good and will work well with multiple packages sharing one source tree. My plan for the command line interface is that cabal configure/build/install in a dir with multiple .cabal files will act on all of them. Individual packages, or components within packages will be selectable by name, e.g. "cabal configure" (configures all packages) "cabal build foo" (builds just target foo). I'm not quite sure how to handle name clashes, but I expect we can work something out. For example, a package A containing exe A and B. Does A refer to the package (components A and B) or just to the component A? Duncan

Mario Blažević

8:54 p.m.

On Mon, Jan 10, 2011 at 6:16 PM, Duncan Coutts

...

wrote:

...

My plan for the command line interface is that cabal configure/build/install in a dir with multiple .cabal files will act on all of them. Individual packages, or components within packages will be selectable by name, e.g. "cabal configure" (configures all packages) "cabal build foo" (builds just target foo).

+1. This would perfectly fit and improve on my current mode of operation. I'm not quite sure how to handle name clashes, but I expect we can

...

work something out. For example, a package A containing exe A and B. Does A refer to the package (components A and B) or just to the component A?

I would assume the package, because Cabal is normally all about packages. You can't specify you want to build a particular executable at the moment, can you? Would Cabal in your scheme track dependencies between multiple packages sharing the same repository? If I have multiple related packages in a single directory, will "cabal build foo" automatically configure and build all packages that foo depends on? How will you hide the module files of all other packages from the compiler while it's building one? I assume you'll copy all the current module files into a separate directory tree before compiling?

Henning Thielemann

11 Jan 11 Jan

7:01 a.m.

On Mon, 10 Jan 2011, Duncan Coutts wrote:

...

My plan for the command line interface is that cabal configure/build/install in a dir with multiple .cabal files will act on all of them. Individual packages, or components within packages will be selectable by name, e.g. "cabal configure" (configures all packages) "cabal build foo" (builds just target foo).

I'm not quite sure how to handle name clashes, but I expect we can work something out. For example, a package A containing exe A and B. Does A refer to the package (components A and B) or just to the component A?

If you think about all the consequences, then I think the extension to multiple packages in one directory causes more problems than it solves. As I said, my experience so far is, that even multiple packages in one darcs repository do not work well for me. Solution of other problems, e.g. reliable and predictable management of multiple installed versions of a package would be much more important at least for me ...

Peter Simons

12 Jan 12 Jan

4:33 a.m.

Hi Henning,

...

The name does not have to be pkgname.cabal. You can choose any name with extension .cabal. Cabal complains about multiple files with that extension.

duh, I didn't know that! I assumed that the "foo" part in "foo.cabal" is significant in some way, but apparently it's not.

...

So you could in principle call it description.cabal consistently in all your packages.

Is it also possible to use a package-specific name for Setup.hs? If I'd be writing a package called "foo", could I use the name "foo.cabal" and "foo.setup" to designate my build instructions? I'd also be happy to call the "Setup.hs" file "Setup-foo.hs" or "Foo-setup.hs" or whatever, as long as there's a package-specific component in the name that matches the one I used for the Cabal file. If that were the case, then multiple packages could be stored in one directory, and a build call like cabal configure --package=foo would be unambiguous. Take care, Peter

Henning Thielemann

6:59 a.m.

On Wed, 12 Jan 2011, Peter Simons wrote:

...

...
So you could in principle call it description.cabal consistently in all your packages.

Is it also possible to use a package-specific name for Setup.hs? If I'd be writing a package called "foo", could I use the name "foo.cabal" and "foo.setup" to designate my build instructions? I'd also be happy to call the "Setup.hs" file "Setup-foo.hs" or "Foo-setup.hs" or whatever, as long as there's a package-specific component in the name that matches the one I used for the Cabal file.

If that were the case, then multiple packages could be stored in one directory, and a build call like

cabal configure --package=foo

would be unambiguous.

I think this leads to nothing - you would also need directories like dist-foo and maybe more in the future. The one-directory-to-one-package relation makes things easy and that's somehow what directories are for. The other way round makes more sense to me: Give all package Cabal files the same name (main.cabal?), since the package name is already given by the directory name. Maybe in the future someone wants a Cabal include mechanism that allows to write one Cabal file per executable and to put them together according to include statements in main.cabal. The discussion and the personal preferences are certainly similar to whether to put many modules into one file, or whether to define identifiers for unqualified import and export many modules by one main module. My question is: What is really the benefit of having multiple packages in one directory? kahl@cas.mcmaster.ca has commented on this question, but his use case didn't convince me. Building many packages at once, an inter-package Make so to speak, would be nice, but this could be separate from the technique of building one package.

Magnus Therning

7:18 a.m.

On Wed, Jan 12, 2011 at 11:59, Henning Thielemann wrote:

...

On Wed, 12 Jan 2011, Peter Simons wrote:

...
...
So you could in principle call it description.cabal consistently in all your packages.

Is it also possible to use a package-specific name for Setup.hs? If I'd be writing a package called "foo", could I use the name "foo.cabal" and "foo.setup" to designate my build instructions? I'd also be happy to call the "Setup.hs" file "Setup-foo.hs" or "Foo-setup.hs" or whatever, as long as there's a package-specific component in the name that matches the one I used for the Cabal file.

If that were the case, then multiple packages could be stored in one directory, and a build call like

cabal configure --package=foo

would be unambiguous.

I think this leads to nothing - you would also need directories like dist-foo and maybe more in the future. The one-directory-to-one-package relation makes things easy and that's somehow what directories are for. The other way round makes more sense to me: Give all package Cabal files the same name (main.cabal?), since the package name is already given by the directory name. Maybe in the future someone wants a Cabal include mechanism that allows to write one Cabal file per executable and to put them together according to include statements in main.cabal.

The discussion and the personal preferences are certainly similar to whether to put many modules into one file, or whether to define identifiers for unqualified import and export many modules by one main module.

My question is: What is really the benefit of having multiple packages in one directory? kahl@cas.mcmaster.ca has commented on this question, but his use case didn't convince me. Building many packages at once, an inter-package Make so to speak, would be nice, but this could be separate from the technique of building one package.

Couldn't that use case also be solved by allowing multiple Library sections in the Cabal file (similar to how multiple Executable sections are allowed). This may, or may not, be easier to deal with than having multiple Cabal files. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

Mario Blažević

9:47 a.m.

On 11-01-12 06:59 AM, Henning Thielemann wrote:

...

On Wed, 12 Jan 2011, Peter Simons wrote:

My question is: What is really the benefit of having multiple packages in one directory? kahl@cas.mcmaster.ca has commented on this question, but his use case didn't convince me. Building many packages at once, an inter-package Make so to speak, would be nice, but this could be separate from the technique of building one package.

I maintain multiple packages in a single directory and a single Darcs repository because I treat it all as a single project. It also allows me to move module files from one package to another without losing the file history. Splitting and merging packages, for example, affects only the package description files. I guess one could achieve a similar effect by keeping the packages in subdirectories of a common project directory, which would act as a Darcs repository. But that kind of directory hierarchy would sprawl more.

Kathleen Fisher

12:54 p.m.

On Jan 12, 2011, at 3:59 AM, Henning Thielemann wrote:

...

My question is: What is really the benefit of having multiple packages in one directory? kahl@cas.mcmaster.ca has commented on this question, but his use case didn't convince me. Building many packages at once, an inter-package Make so to speak, would be nice, but this could be separate from the technique of building one package.

I can explain why the question occurred to me, but I'm a newbie to Haskell library construction, so I could have just set things up badly. I have two libraries that both implement embedded domain specific languages in haskell, pads and forest, with forest depending on pads. Because they are both languages, I put the Pads modules in Language.Pads.XXX and the Forest modules in Language.Forest.XXX. I have a single development space with a directory Language with subdirectories Pads and Forest. Now I want to to be able to install these libraries with cabal. The place where it seems like I am supposed to put the cabal file is the directory containing the Language directory, but that means I need one cabal file for Pads and another for Forest. Rearranging my directory structure to separate the two packages is a pain because the files are under version control in CVS. I'm guessing I'm missing the right model for how to arrange Haskell source code bases. Suggestions for how I should do things differently? Kathleen

Magnus Therning

2:32 p.m.

On 12/01/11 17:54, Kathleen Fisher wrote:

...

On Jan 12, 2011, at 3:59 AM, Henning Thielemann wrote:

...
My question is: What is really the benefit of having multiple packages in one directory? kahl@cas.mcmaster.ca has commented on this question, but his use case didn't convince me. Building many packages at once, an inter-package Make so to speak, would be nice, but this could be separate from the technique of building one package.

I can explain why the question occurred to me, but I'm a newbie to Haskell library construction, so I could have just set things up badly.

I have two libraries that both implement embedded domain specific languages in haskell, pads and forest, with forest depending on pads. Because they

Will pads be used on its own to the extent that it's painful to always get forest and pads together?

...

are both languages, I put the Pads modules in Language.Pads.XXX and the Forest modules in Language.Forest.XXX. I have a single development space with a directory Language with subdirectories Pads and Forest. Now I want to to be able to install these libraries with cabal. The place where it seems like I am supposed to put the cabal file is the directory containing the Language directory, but that means I need one cabal file for Pads and another for Forest. Rearranging my directory structure to separate the two packages is a pain because the files are under version control in CVS.

With more modern version control systems you can split a single repo into multiple repos, with the history for the files in the different repos intact.

...

I'm guessing I'm missing the right model for how to arrange Haskell source code bases. Suggestions for how I should do things differently?

Splitting things is often good, but sometimes it's easy to split things even when it's unnecessary. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

Henning Thielemann

2:53 p.m.

Kathleen Fisher schrieb:

...

I have two libraries that both implement embedded domain specific languages in haskell, pads and forest, with forest depending on pads. Because they are both languages, I put the Pads modules in Language.Pads.XXX and the Forest modules in Language.Forest.XXX. I have a single development space with a directory Language with subdirectories Pads and Forest. Now I want to to be able to install these libraries with cabal. The place where it seems like I am supposed to put the cabal file is the directory containing the Language directory, but that means I need one cabal file for Pads and another for Forest. Rearranging my directory structure to separate the two packages is a pain because the files are under version control in CVS.

So your problem is maybe more a problem of CVS rearrangement than a Haskell packaging problem? If you have direct access to the CVS repository you might rearrange the '*,v' files in the CVS repository as you need. This rearrangement will not be logged by CVS, of course, but that is a known deficiency of CVS.

...

I'm guessing I'm missing the right model for how to arrange Haskell source code bases. Suggestions for how I should do things differently?

I don't know enough about your languages, but putting Pads and Forest into two packages sounds reasonable. I would move them into separate directories if possible.

Christian Maeder

13 Jan 13 Jan

5:50 a.m.

Am 12.01.2011 20:53, schrieb Henning Thielemann:

...

Kathleen Fisher schrieb:

...
I have two libraries that both implement embedded domain specific languages in haskell, pads and forest, with forest depending on pads. Because they are both languages, I put the Pads modules in Language.Pads.XXX and the Forest modules in Language.Forest.XXX. I have a single development space with a directory Language with subdirectories Pads and Forest. Now I want to to be able to install these libraries with cabal. The place where it seems like I am supposed to put the cabal file is the directory containing the Language directory, but that means I need one cabal file for Pads and another for Forest. Rearranging my directory structure to separate the two packages is a pain because the files are under version control in CVS.

So your problem is maybe more a problem of CVS rearrangement than a Haskell packaging problem? If you have direct access to the CVS repository you might rearrange the '*,v' files in the CVS repository as you need. This rearrangement will not be logged by CVS, of course, but that is a known deficiency of CVS.

...
I'm guessing I'm missing the right model for how to arrange Haskell source code bases. Suggestions for how I should do things differently?

I don't know enough about your languages, but putting Pads and Forest into two packages sounds reasonable. I would move them into separate directories if possible.

I would add two files pads.mycabal and forest.mycabal and use a wrapper script that temporarily copies one file (i.e. argument $1) $1.mycabal to $1.cabal for cabal calls. Christian

Duncan Coutts

12:51 p.m.

On 12 January 2011 17:54, Kathleen Fisher wrote:

...

I can explain why the question occurred to me, but I'm a newbie to Haskell library construction, so I could have just set things up badly.

I have two libraries that both implement embedded domain specific languages in haskell, pads and forest, with forest depending on pads. Because they are both languages, I put the Pads modules in Language.Pads.XXX and the Forest modules in Language.Forest.XXX. I have a single development space with a directory Language with subdirectories Pads and Forest. Now I want to to be able to install these libraries with cabal. The place where it seems like I am supposed to put the cabal file is the directory containing the Language directory, but that means I need one cabal file for Pads and another for Forest. Rearranging my directory structure to separate the two packages is a pain because the files are under version control in CVS.

I'm guessing I'm missing the right model for how to arrange Haskell source code bases. Suggestions for how I should do things differently?

I think the simplest model would be as follows: reporoot/ reporoot/pads/ reporoot/pads/pads.cabal reporoot/pads/Language/Pads/XXX.hs reporoot/forest/ reporoot/forest/forest.cabal reporoot/forest/Language/Forest/XXX.hs So the top level of the source repository contains two subdirs, one for each package. If you want them to be separate packages then this is the simplest. I appreciate that CVS does not make it easy to move files and directories around. I agree that if you typically develop these two packages together but want to be able to distribute them separately then it would be nicer to be able to have multiple .cabal files in one directory. Duncan

Henning Thielemann

12:55 p.m.

Duncan Coutts wrote:

...

I think the simplest model would be as follows:

reporoot/ reporoot/pads/ reporoot/pads/pads.cabal reporoot/pads/Language/Pads/XXX.hs

reporoot/forest/ reporoot/forest/forest.cabal reporoot/forest/Language/Forest/XXX.hs

...

I agree that if you typically develop these two packages together but want to be able to distribute them separately then it would be nicer to be able to have multiple .cabal files in one directory.

Or just write $ for dir in pads forest; do (cd $dir; cabal install); done

Duncan Coutts

1:15 p.m.

On 13 January 2011 17:55, Henning Thielemann wrote:

...

Duncan Coutts wrote:

...
I think the simplest model would be as follows:

reporoot/ reporoot/pads/ reporoot/pads/pads.cabal reporoot/pads/Language/Pads/XXX.hs

reporoot/forest/ reporoot/forest/forest.cabal reporoot/forest/Language/Forest/XXX.hs

...

I agree that if you typically develop these two packages together but want to be able to distribute them separately then it would be nicer to be able to have multiple .cabal files in one directory.

Or just write

$ for dir in pads forest; do (cd $dir; cabal install); done

That's assuming the dependencies go in that order. With the next version of cabal you will be able to say: $ cabal install pads/ forest/ and it will work out the dependency order and install both. Duncan

Duncan Coutts

10 Jan 10 Jan

1:37 p.m.

On 7 January 2011 22:48, Kathleen Fisher wrote:

...

Hi,

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? If it doesn't, is that just because it hasn't been implemented, or is there a Good Reason?

It's mostly because it has not been implemented yet. It's a little harder than it looks however because it involves a change in the Cabal spec, not just in the tools. The Cabal spec describes the interface between package build systems and the build agent (or user). That will need to be extended to allow for multiple .cabal files with a single Setup.hs in one directory. We'll want to do it in such a way that it does not impose too high costs on all custom build systems, so it'll have to be optional. On a related note, I'm currently implementing this: $ cabal install ./pads/ ./forest/ or $ cabal install ./pads/pads.cabal ./forest/forest.cabal That is, if you can specify local dirs and/or .cabal files as install targets, though each directory will still have to contain just one .cabal file. But that syntax will extend naturally once we have support for multiple .cabal files sharing one Setup.hs in one directory. Also: $ cabal install ./lib/foo-1.0.tar.gz http://example.com/~user/bar-1.0.tar.gz That is, local and remote tarballs. Duncan

Christian Maeder

11 Jan 11 Jan

3:37 a.m.

Am 10.01.2011 19:37, schrieb Duncan Coutts: [...]

...

between package build systems and the build agent (or user). That will need to be extended to allow for multiple .cabal files with a single Setup.hs in one directory. We'll want to do it in such a way that it [...] .cabal file. But that syntax will extend naturally once we have support for multiple .cabal files sharing one Setup.hs in one directory. [...]

For cabal packages with "build-type: Simple" a Setup.hs file should not be necessary and considered. Christian

5242

Age (days ago)

5248

Last active (days ago)

List overview

Download

25 comments

10 participants

participants (10)

Antoine Latter
Christian Maeder
Duncan Coutts
Henning Thielemann
Ivan Lazar Miljenovic
kahl＠cas.mcmaster.ca
Kathleen Fisher
Magnus Therning
Mario Blažević
Peter Simons