Thanks to everyone for input on this, I was completely unaware of Paths_* being provided by cabal. I've just pushed a yesodVersion function to the ver0.7 branch on Git. For the record, you *do* need to include the Paths_* module in other-modules in order to make your code usable. Michael On Tue, Dec 21, 2010 at 2:42 PM, Simon Meier wrote:

2010/12/21 Felipe Almeida Lessa

...

2010/12/21 Michael Snoyman :

...

Do you know of any prior art that does this? Having a package import files generated by cabal seems like it could cause problems.

Although Cabal's documentation only mentions 'getDataFileName' [1], the API states that the Paths module should "enable [the packages] to find their version number" [2].  So that's the intended use, even if not very well documented.  Just remember to put the Paths in 'other-modules' [1].

I'm not sure, if it should be put in 'other-modules' as the your_project_paths.hs is an autogenerated file, which you don't want to ship with your source. I'd rather go for exporting the yesod version via its own API and use the paths file to implement that functionality. One thing, I always found useful is to have a directory   interactive-only-src/ containing a copy of the autogenerated paths file as in   interactive-only-src/your_project_paths.hs together with the .ghci file containing a line   :set -iinteractive-only-src This way you GHCi works as intended and the paths file is autogenerated and compiled in upon install.

cheers, Simon

...

[1] http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.ht... [2] http://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Distribution...

Cheers! =)

-- Felipe.

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel