How to use cabal's data-files feature and run in-place?

Richard Cobbe

21 Apr 2011 21 Apr '11

9:46 p.m.

I'm running Haskell Platform 2011.2.0.1 on a MacOS 10.6.7 machine (the machine is 64-bit, but I'm running the 32-bit platform). I'm writing an application for personal use, and I'd like to use Cabal to package it up and handle installation. This way, when I'm working on the program, I won't break the reasonably stable installed version and can continue to use it. (I'm not committed to cabal by any means; suggestions for other ways to accomplish the same thing are more than welcome!) I've got some data files I'd like to package with the application, and Cabal's data-files field is the obvious way to do that. The immediate problem, then, is how to access the files -- I can use the generated Paths_pkg module for the "installed" copy of the app, but then I can't run the thing in-place in ghci in the development directory. I did some googling and came across a blog post (http://neilmitchell.blogspot.com/2008/02/adding-data-files-using-cabal.html) which suggested that I provide my own Paths_pkg.hs file that points to the files' location in the development copy. When I build with Cabal, the generated form of this module would override my hand-written one, and it should therefore work in the installed case as well. Unfortunately, that's not happening. Cabal is clearly generating the module; I can see it in dist/build/autogen. But my copy is overriding the autogenerated one, even for cabal builds -- at least, that's what I'm seeing when I run the binary out of dist/build/<package>/<executable>. Is there a way to be able to use data files in both contexts? FWIW, I'm running cabal as runhaskell Setup.hs configure --user runhaskell Setup.hs build Thanks much, Richard

Show replies by date

Antoine Latter

22 Apr 22 Apr

12:27 a.m.

On Thu, Apr 21, 2011 at 8:46 PM, Richard Cobbe wrote:

...

I'm running Haskell Platform 2011.2.0.1 on a MacOS 10.6.7 machine (the machine is 64-bit, but I'm running the 32-bit platform).

I'm writing an application for personal use, and I'd like to use Cabal to package it up and handle installation. This way, when I'm working on the program, I won't break the reasonably stable installed version and can continue to use it.

(I'm not committed to cabal by any means; suggestions for other ways to accomplish the same thing are more than welcome!)

I've got some data files I'd like to package with the application, and Cabal's data-files field is the obvious way to do that. The immediate problem, then, is how to access the files -- I can use the generated Paths_pkg module for the "installed" copy of the app, but then I can't run the thing in-place in ghci in the development directory.

I did some googling and came across a blog post (http://neilmitchell.blogspot.com/2008/02/adding-data-files-using-cabal.html) which suggested that I provide my own Paths_pkg.hs file that points to the files' location in the development copy. When I build with Cabal, the generated form of this module would override my hand-written one, and it should therefore work in the installed case as well.

Unfortunately, that's not happening. Cabal is clearly generating the module; I can see it in dist/build/autogen. But my copy is overriding the autogenerated one, even for cabal builds -- at least, that's what I'm seeing when I run the binary out of dist/build/<package>/<executable>.

Is there a way to be able to use data files in both contexts?

FWIW, I'm running cabal as

runhaskell Setup.hs configure --user runhaskell Setup.hs build

1. A side note - using the 'cabal' command line tool is easier for many tasks than 'runhaskell Setup'. In particular, it does a user install by default. 2. Here's what I do for the paths situation: In the package description, create a CPP option so you know you're compiling via Cabal:

...

Cpp-options: -DCABAL

Then create a module to wrap around the autogenerated paths module, making sure to put the CPP Language pragma at the top:

...

{-# LANGUAGE CPP #-}

You can then use #ifdef CABAL to decide to re-export the Cabal autogenerated paths functionality, or to use the ones you've written yourself (based on the current directory or whatever you need). I hope that this helps! I don't have any examples on hand at the moment. Antoine

...

Thanks much,

Richard

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Richard Cobbe

7:57 a.m.

New subject: How to use cabal's data-files feature and run in-place?

On Thu, Apr 21, 2011 at 11:27:10PM -0500, Antoine Latter wrote:

...

1. A side note - using the 'cabal' command line tool is easier for many tasks than 'runhaskell Setup'. In particular, it does a user install by default.

Interesting -- didn't know that was possible. I didn't see that in the Cabal manual; section 4 gives instructions entirely in terms of 'runhaskell Setup'. Am I overlooking something?

...

2. Here's what I do for the paths situation:

In the package description, create a CPP option so you know you're compiling via Cabal:

...
Cpp-options: -DCABAL

Then create a module to wrap around the autogenerated paths module, making sure to put the CPP Language pragma at the top:

...
{-# LANGUAGE CPP #-}

You can then use #ifdef CABAL to decide to re-export the Cabal autogenerated paths functionality, or to use the ones you've written yourself (based on the current directory or whatever you need).

I hope that this helps! I don't have any examples on hand at the moment.

That sounds like it should work, thanks. I'd been thinking about using CPP tricks, but I didn't know how to use CPP for a module in a way that would work with the rest of the toolchain -- in particular, with both ghc and ghci. I'll give it a shot. Thanks! Richard

Daniel Fischer

8:19 a.m.

On Friday 22 April 2011 13:57:36, Richard Cobbe wrote:

...

On Thu, Apr 21, 2011 at 11:27:10PM -0500, Antoine Latter wrote:

...
1. A side note - using the 'cabal' command line tool is easier for many tasks than 'runhaskell Setup'. In particular, it does a user install by default.

Interesting -- didn't know that was possible. I didn't see that in the Cabal manual; section 4 gives instructions entirely in terms of 'runhaskell Setup'. Am I overlooking something?

On the one hand, the Cabal user's guide is a little out of date. More importantly, there's a difference between the Cabal library and the 'cabal' executable (which you get from the cabal-install package). The Cabal user's guide can't assume that you have the cabal executable, but it can assume you have runhaskell (since without a Haskell implementation, installing Haskell libraries is doomed to fail anyway). However, if the user's guide gets updated, the cabal way will probably (and definitely should) be added.

Richard Cobbe

23 Apr 23 Apr

9:28 a.m.

New subject: How to use cabal's data-files feature and run in-place?

On Thu, Apr 21, 2011 at 11:27:10PM -0500, Antoine Latter wrote:

...

2. Here's what I do for the paths situation:

In the package description, create a CPP option so you know you're compiling via Cabal:

...
Cpp-options: -DCABAL

Then create a module to wrap around the autogenerated paths module, making sure to put the CPP Language pragma at the top:

...
{-# LANGUAGE CPP #-}

You can then use #ifdef CABAL to decide to re-export the Cabal autogenerated paths functionality, or to use the ones you've written yourself (based on the current directory or whatever you need).

I hope that this helps! I don't have any examples on hand at the moment.

Thanks -- works like a charm! I'm particularly pleased to see that ghci supports cpp. Richard

Max Rabkin

22 Apr 22 Apr

3:23 a.m.

On Fri, Apr 22, 2011 at 03:46, Richard Cobbe wrote:

...

Unfortunately, that's not happening. Cabal is clearly generating the module; I can see it in dist/build/autogen. But my copy is overriding the autogenerated one, even for cabal builds -- at least, that's what I'm seeing when I run the binary out of dist/build/<package>/<executable>.

I'm no Cabal expert, but the first thing I'd try is to leave your copy out of the list of included files in the Cabal file. --Max

Richard Cobbe

7:59 a.m.

New subject: How to use cabal's data-files feature and run in-place?

On Fri, Apr 22, 2011 at 09:23:32AM +0200, Max Rabkin wrote:

...

On Fri, Apr 22, 2011 at 03:46, Richard Cobbe wrote:

...
Unfortunately, that's not happening. Cabal is clearly generating the module; I can see it in dist/build/autogen. But my copy is overriding the autogenerated one, even for cabal builds -- at least, that's what I'm seeing when I run the binary out of dist/build/<package>/<executable>.

I'm no Cabal expert, but the first thing I'd try is to leave your copy out of the list of included files in the Cabal file.

I'm not listing the included files, actually -- all I have is a "main-is:" setting, and ghc is pulling the rest in through automatic dependency detection. Actually, that suggests another strategy: if there's a way in the cabal file to configure ghc's search path, then I could make sure that the cabal-generated file is seen before mine. It's a little fragile, though, as it depends on the precise place that cabal puts the generated file. I'll look into that. Richard

balodja

11:41 a.m.

New subject: How to use cabal's data-files feature and run in-place?

On Fri, 2011-04-22 at 05:51 +0400, Richard Cobbe wrote:

...

I did some googling and came across a blog post

...

which suggested that I provide my own Paths_pkg.hs file that points to

...

files' location in the development copy. When I build with Cabal, the generated form of this module would override my hand-written one, and it should therefore work in the installed case as well.

Unfortunately, that's not happening. Cabal is clearly generating the module; I can see it in dist/build/autogen. But my copy is overriding

(http://neilmitchell.blogspot.com/2008/02/adding-data-files-using-cabal.html) the the

...

autogenerated one, even for cabal builds -- at least, that's what I'm seeing when I run the binary out of dist/build/<package>/<executable>.

Is there a way to be able to use data files in both contexts?

For such purposes I use separate directory for Paths_pkg.hs and don't notice it in pkg.cabal. For example, imagine "src" directory with source files (appropriately mentioned in pkg.cabal with "hs-source-dirs: src") and additional "plugs" directory with "Paths_pkg.hs" (that is not mentioned in pkg.cabal). In such case cabal builds project with autogenerated Paths_pkg.hs and ghci also can be launched in "src" directory with "ghci Main.hs -i../plugs". Vladimir

Henning Thielemann

24 Apr 24 Apr

7:50 a.m.

New subject: How to use cabal's data-files feature and run in-place?

balodja schrieb:

...

For such purposes I use separate directory for Paths_pkg.hs and don't notice it in pkg.cabal. For example, imagine "src" directory with source files (appropriately mentioned in pkg.cabal with "hs-source-dirs: src") and additional "plugs" directory with "Paths_pkg.hs" (that is not mentioned in pkg.cabal). In such case cabal builds project with autogenerated Paths_pkg.hs and ghci also can be launched in "src" directory with "ghci Main.hs -i../plugs".

or you run from your package directory with pkg$ ghci -i:src:plugs Main This only works, if the module Main has filename Main.hs Otherwise start with pkg$ ghci -i:src:plugs src/Main.hs

5141

Age (days ago)

5143

Last active (days ago)

List overview

Download

8 comments

6 participants

participants (6)

Antoine Latter
balodja
Daniel Fischer
Henning Thielemann
Max Rabkin
Richard Cobbe