On 12.10.2010 13:45, Magnus Therning wrote:

On Tue, Oct 12, 2010 at 10:20, Dmitry V'yal wrote:

...

Hello,

recently I've cabalized my program and it brought some problems.

First of all, I made use of 'import Paths_<package name>' functionality to get the path of installed data files. It works great, but now I can no longer run my program in ghci because this module is auto-generated by cabal. I tried to supply my own. This way ghci works, but my stub module gets compiled into the binary in place of auto-generated. And things break again. What's the best way to overcome it?

Create a file called .ghci in the directory where you run ghci and make it contains something like this:

:set -idist/build/autogen

...

And another question. I'd like to make my program output it's version string. Of course, I can hardcode it into sources, but I've already specified one in the cabal file. Is there any way to get it back in the run time?

It's in Paths_<package name> as the variable 'version'.

/M

That's perfectly what I was looking for, thanks a lot! By the way, the 'version' variable doesn't mentioned in Cabal user guide, or at least I missed it. Is it documented somewhere?

On 13 October 2010 02:00, Magnus Therning wrote:

On Tue, Oct 12, 2010 at 15:34, Dmitry V'yal wrote:

...

By the way, the 'version' variable doesn't mentioned in Cabal user guide, or at least I missed it. Is it documented somewhere?

I don't know, I think I found it in the source more or less by mistake :-)

Yeah, I think that's the common consensus; there is _some_ documentation of the Paths_foo module in the Cabal user guide, but it doesn't cover much. One thing I do wish was possible: the ability to use a "stub" Paths_foo module for testing purposes (as currently you have to have done a "cabal configure && cabal build" to get it), but I couldn't find a way to do so without Cabal packaging the stub version when creating the distribution tarball :s -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

I do this using a .ghci file. For Hoogle I have a file called Paths.hs with the module name Paths_hoogle and stub exports. I then have my .ghci file as: :load Main.hs Paths.hs Now Paths.hs will never interfere, or be picked up in ghc --make, because it has the wrong name - but is used in ghci. Thanks, Neil On Wed, Oct 13, 2010 at 6:45 AM, Antoine Latter wrote:

On Tue, Oct 12, 2010 at 10:41 PM, Ivan Lazar Miljenovic wrote:

...

On 13 October 2010 02:00, Magnus Therning wrote:

...

On Tue, Oct 12, 2010 at 15:34, Dmitry V'yal wrote:

...

By the way, the 'version' variable doesn't mentioned in Cabal user guide, or at least I missed it. Is it documented somewhere?

I don't know, I think I found it in the source more or less by mistake :-)

Yeah, I think that's the common consensus; there is _some_ documentation of the Paths_foo module in the Cabal user guide, but it doesn't cover much.

One thing I do wish was possible: the ability to use a "stub" Paths_foo module for testing purposes (as currently you have to have done a "cabal configure && cabal build" to get it), but I couldn't find a way to do so without Cabal packaging the stub version when creating the distribution tarball :s

I've used CPP, something like:

module MyPaths  ( export contents of Paths_magic ) where

#ifdef SOME_DEF_SET_BY_CABAL import Paths_magic #else

mock implementation of paths magic here

#endif

Then in your .cabal file declare the define which causes it to use the real magic paths module. When not compiling via cabal, you'll at least have something sensible (like the current directory or something).

I'm pretty sure I didn't make this up, but I have used it. It's a bit of a pain to set up, though.

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