Re: [Haskell-cafe] a couple of cabal related questions
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 aslat...@gmail.com wrote: On Tue, Oct 12, 2010 at 10:41 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 13 October 2010 02:00, Magnus Therning mag...@therning.org wrote: On Tue, Oct 12, 2010 at 15:34, Dmitry V'yal akam...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a couple of cabal related questions
On 14 October 2010 05:58, Neil Mitchell ndmitch...@gmail.com wrote: 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. Oh, I like this solution. I wonder how well it plays with running ghci in emacs via haskell-mode... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] a couple of cabal related questions
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? 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? Thanks, Dmitry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a couple of cabal related questions
On Tue, Oct 12, 2010 at 10:20, Dmitry V'yal akam...@gmail.com 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 -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a couple of cabal related questions
On 12.10.2010 13:45, Magnus Therning wrote: On Tue, Oct 12, 2010 at 10:20, Dmitry V'yalakam...@gmail.com 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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a couple of cabal related questions
On Tue, Oct 12, 2010 at 15:34, Dmitry V'yal akam...@gmail.com wrote: On 12.10.2010 13:45, Magnus Therning wrote: On Tue, Oct 12, 2010 at 10:20, Dmitry V'yalakam...@gmail.com 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? I don't know, I think I found it in the source more or less by mistake :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a couple of cabal related questions
On 13 October 2010 02:00, Magnus Therning mag...@therning.org wrote: On Tue, Oct 12, 2010 at 15:34, Dmitry V'yal akam...@gmail.com 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.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a couple of cabal related questions
On Tue, Oct 12, 2010 at 10:41 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 13 October 2010 02:00, Magnus Therning mag...@therning.org wrote: On Tue, Oct 12, 2010 at 15:34, Dmitry V'yal akam...@gmail.com 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