Can the stack working directory and ghc-options for a project be configured

[psilospore]

Your environment

Which OS do you use?
MacOS
Which version of GHC do you use and how did you install it?
8.10.7 from ghcup
How is your project built (alternative: link to the project)?
stack
Which LSP client (editor/plugin) do you use?
vscode-haskell mostly but sometimes nvim + coc
Which version of HLS do you use and how did you install it?
2.0.0.0 from ghcup
Have you configured HLS in any way (especially: a hie.yaml file)?
Yes but I'm looking to avoid doing so

What's wrong?

I have a project that is slow to compile so locally I build with the following
alias sb="stack build --fast --ghc-options -j"
alias sbf="stack build --fast --ghc-options -j --file-watch"

However HLS seems to clash with that and I frequently get modules that recompile and note that the Optimization flags have changed.

So I did the following solution:

hie.yaml with a different stack.yaml

cradle:
  stack:
    stackYaml: "./stack-hls.yaml"
...

Then my stack-hls.yaml

# By default use .stack-work however If this seems to clash with another stack process 
# you can change this to .stack-work-hls
# That will use a different directory for the hls process
# However it will not share the same build cache as the other stack process
work-dir: .stack-work-hls

# -O0 disables optimizations and is equivalent stack --fast
# -j enables parallel builds
# Add the following aliases as well:
# alias sb="stack build --fast --ghc-options -j"
# alias sbf="stack build --fast --ghc-options -j --file-watch"
# I normally develop with sbf
ghc-options:
  "$everything": -j -O0

This works great. HLS seems to compile my project really quickly now. I don't have build locks.
However I don't like:

1. having a separate stack.yaml for local development and deployment that would need to be synced.
2. Having to create a hie.yaml file. I guess this isn't so bad so more of a minor nit pick
3. HLS for example doesn't work on my machine but seems to work on others. This feels like it should be something I configure for just me. So I don't want to check this stuff in source control.

So I was wondering if there a way to configure the stack working directory and my ghc-options for the project with HLS ideally in the settings?

[fendor]

Hi!

So I was wondering if there a way to configure the stack working directory and my ghc-options for the project with HLS ideally in the settings?

As far as I know, not currently. I think, we are passing in -O0 and -j ourselves to the build of local packages, but the issue is the work-dir. For cabal, we set the work-dir (called builddir) to ~/.cache/hie-bios/...-dist-newstyle or similar. But Stack doesn't support absolute paths for work-dir (last time we checked). The reasoning for forcing relative paths for work-dir is likely outdated.

So, ideally, I think your best course of action is to raise that issue with stack maintainers (allowing HLS to set the work-dir to some absolute path), maybe even patching stack yourself, and then we can permanently work set the work-dir and you wouldn't need a stack.yaml for development.

FYI, we decided against choosing some .hls-stack-work directory in the current working directory as the work-dir. I don't remember the exact reasoning (I am getting old :( ), but it was something along the line of, we don't want to interfere with the user directory if possible.

[TeofilC]

I think this is related to haskell/hie-bios#345

[fendor]

As haskell/hie-bios#345 (comment) points out, you may set the STACK_WORK environment variable. Closing this issue as solved then.