I'm using cabal 3.2.0.0. I've created a cabal.project file which points to many submodules. When I run cabal build all and there is an error in a submodule, the path to the file with an error is shown relative to the cabal file of the submodule. This is very inconvenient with vim's :make. Is there a way to turn the path to relative from .project file? Or at least into absolute path.
Well, I've not found found how to do it with cabal, but I wrote a small vim plugin that band-aid fixes this problem.
https://github.com/d86leader/vim-config/blob/ac1651544b5c61f3dfa4f19a00946efb49056793/autoload/hs_cabal.vim
Related
When I use the data-files feature of cabal, it generates a Paths_pkgname.hs module that lives in the dist/ folder.
However, intero is unable to find this file (or generate it on its own), and I can't find any means to pass an option to hint at its position.
Note: Somewhere else (on SO?) I picked up the trick when using ghci to make a dummy only-for-ghci/Paths_.hs that is only brought into scope through :set -ionly-for-ghci being set in .ghci. This won't apply for intero though, as its invocation in intero.el specificcally instructs it to ignore the .ghci file.
I was only building my project using cabal and nix. It turns out that because Intero is stack-centric, building the project with stack build does indeed put a Paths_.. module in a place where Intero searches.
Syntastic works great in my system with hdevtools and hlint. But if I'm editing a file under a test directory, importing packages that are exclusively under the test-suite configuration of the cabal package, it marks my imports as bogus and tells me to include them in my cabal file. The same problem happens with the hs-source-dir, it only finds the ones under the library or executable directory.
There is no silver bullet. You can either set g:syntastic_haskell_hdevtools_args and friends to the proper flags for your project, or write a wrapper script similar to this and point g:syntastic_haskell_hdevtools_exec to it. Syntastic has no built-in support for looking at cabal files.
Is it possible to use HLint.hs file to customize HLint messages in EclipseFP?
I tried adding a HLint.hs file in the project root containing:
import "hint" HLint.HLint
ignore "Use camelCase"
but it has no effect:
Update:
For HLint to pick up the changes in the HLint.hs file it is required to run Cabal install dependencies by right clicking on the project:
EclipseFP runs HLint passing the project folder as the working directory, so a HLint.hs file there will be taken into account. HLint only runs when needed, so after putting the HLint.hs file or modifying it you need to touch your source files so they get rebuilt again and HLint runs on them again.
I have ghc in my path, have set up yesod init and cabal built it.
Now, when I 'yesod devel' I get :
cabal: Cannot find the program 'ghc' at 'yesod-ghc-wrapper' or on the path
ghc IS on the path!
thanks
I've seen that if the path to the yesod bin directory under cabal is not in my PATH.
Try changing your PATH to include the yesod directory and see if it goes away.
For example, in my .bash_profile I have:
export PATH=$PATH:/Users/username/Library/Haskell/ghc-7.4.2/lib/yesod-bin-1.2.2/bin/
In the project pandoc, Paths_pandoc is imported in Shared.hs. Paths_pandoc.hs is located in dist/build/autogen/. How is it generated and what does it do for pandoc.
It's a file that is generated by Cabal.
When you specify Data-files: in your .cabal file for your project, those files will be copied to a good location for "data files" on your system when you run cabal install. On Windows, this might be "C:\Program Files\Something" and on Linux it might be "/usr/share/something" (At least when you do a --system install).
Your code needs to know where the files were copied to, so Cabal generates that special module, which contains variables for the install paths that were used to copy the data files, so that your code can find the installed data files.
The module does also contain other information that Cabal provides for you, but the primary purpose of the module is what I just described.
See this blog post for more information.