Is there a cabal option to rebuild (or even run the tests and do other stuff) on every source file change? With Stack there is the --file-watch option, anything similar for Cabal? Or do people just use ghcid for that?
When I use stack I have the following files in the root:
stack.yaml
package.yaml
myProject.cabal
The last one is built automatically by stack build, based on the other two. Accordingly, I expect myProject.cabal to be updated when the other two files change, but that is not the case. As far as I can tell one must delete the cabal file for a new one to be generated.
First obvious question is: Why? Why doens't Stack rebuild the cabal if obviously needs to be changed?
Second question: How do I tell Stack to rebuild the cabal file? I don't want to manually delete the cabal file every time I do a version change or tweak package.yaml.
What I've tried:
One option is to manually delete the cabal file manually, which just seems like a terrible workflow. The other option is to always delete the cabal file (with a custom makefile) this seems hacky and would trigger a full rebuild (since the cabal file changed) everytime!
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.
1 Context
I am involved in a Haskell project that involves lots of C-bits and FFI. So I find myself frequently running and re-running commands like
$ stack build
$ stack build --force-dirty
$ stack clean
$ rm ./.stack-work
over and over in order for the C-bits to be linked properly to the Haskell bits. Put differently, sometimes things just work when running stack build, and sometimes they don't (in which case I'm forced to cycle through the above commands over and over until my project builds properly).
This means I don't have a proper understanding of how stack (through ghc) assembles the C-bits before assembling the Haskell bits. So here is one question to help me start clearing up my confusion:
2 Question
Are there any noteworthy difference between running stack clean and deleting the contents of the .stack-work directory? Are there cases where deleting the .stack-work directory is needed as a good precaution to ensure that you are actually running a clean build?
As you can see by reading the source here:
https://github.com/commercialhaskell/stack/blob/master/src/Stack/Clean.hs
There are two levels, full and shallow. I think shallow seems to be the default. It seems to be able to clean specific packages, or if you don't provide no options at all, it'll clean everything but extra-deps in local packages.
How can I "install" a local (ie it is on my hard-drive, not on the internet) .hs file to use it across multiple programs? Specifically, if I edit the library, those edits should be available to all programs, so no copy-pasting the library into every program’s directory.
To compile my programs, I still want to type ghc main.hs, not a page of file-paths.
This may be obvious from the above, but I don’t have any knowledge of cabal.
Make sure you have the proper Haskell platform installed, including cabal. Alternatively you can use stack, which is more modern and in many ways better, but IMO cabal is still more practical for a simple project like yours.The following assumes you use cabal on a typical Linux machine.
If not already done, give your file a meaningful hierarchical module name, according to what it does. module Video.Demuxing.FFMPEG or Data.List.Shuffle.Deterministic, for example. Let's assume you call it Foo.Bar.Baz. I.e. the file should begin with
module Foo.Bar.Baz where
... -- start code
Put the file in a corresponding folder structure, i.e.
if not already done, make a new project directory, for example
mkdir /home/Uꜱᴇʀɴᴀᴍᴇ/haskell/foobar
cd /home/Uꜱᴇʀɴᴀᴍᴇ/haskell/foobar
In that project directory make a subdirectory Foo, therein a directory Bar, and put your file in it as Baz.hs.
mkdir -p Foo/Bar
cp WʜᴇʀᴇEᴠᴇʀ/Yᴏᴜʀ/Fɪʟᴇ/Wᴀꜱ/Bᴇꜰᴏʀᴇ.hs Foo/Bar/Baz.hs
Make the file part of a new cabal library.
cabal init
This will ask you a couple of questions, hopefully it'll be clear what to choose. For the most part, the defaults will be fine, in that case always just press enter.
Put everything under version control, if you haven't already. (If you don't know what this is, I suggest you read some Github tutorials. You can skip this step, but the sooner you accustom yourself to some VCS, the better.)
Install your project locally.
cabal install
If everything has worked without errors, you can then, in a Haskell file stored in somewhere else on the computer, simply
import Foo.Bar.Baz
and have everything availably you've defined in that project module. No need to tell GHC where Foo.Bar.Baz is stored when compiling, it has already registered that at this point. You can also launch up ghci anywhere and :m +Foo.Bar.Baz.