Set builddir for cabal #264
Conversation
|
cc @jneira, @bubba , @mpickering |
fendor
requested review from
mpickering,
fendor and
jneira
and removed request for
mpickering
|
I think this is a good compromise, it fixes #195, with no costs for the future. |
|
What needs to change here? Cradle
{ cradleRootDir = wdir
, cradleOptsProg = CradleAction
{ actionName = Types.Cabal
, runCradle = cabalAction wdir mc
, runGhcCmd = \args -> do
-- Workaround for a cabal-install bug on 3.0.0.0:
-- ./dist-newstyle/tmp/environment.-24811: createDirectory: does not exist (No such file or directory)
-- (It's ok to pass 'dist-newstyle' here, as it can only be changed
-- with the --builddir flag and not cabal.project, which we aren't
-- using in our call to v2-exec)
createDirectoryIfMissing True (wdir </> "dist-newstyle" </> "tmp")
-- Need to pass -v0 otherwise we get "resolving dependencies..."
readProcessWithCwd
wdir "cabal" (["v2-exec", "ghc", "-v0", "--"] ++ args) ""
}
} |
|
Not sure if always use another Now hie-bios is using I would prefer to, at least, use a environment variable ( Ideally it should be a field in the |
|
Has anyone combed through ghcide/hls/the rest of his-bios to see if we've hardcoded dist-newstyle anywhere? |
I don't think so - nix style builds are supposed to be deterministic given a
|
I took a quick look and this was the only other concerning occurrence I found. |
I think we want to keep this even with |
|
Using an environment variable seems sensible to me, and I agree it makes sense to have compiler artifacts for the IDE separated from the rest. IMO, I am currently rather opposed to adding fields to Neither HLS nor ghcide will use a hard-coded |
I worry about the "are supposed to be" part. But also by the fact user commands like I cant think of more concrete issues now but i guess that they could arise. I have to admit it doesn't seem like a convincing argument
But that bug is not deterministic, right? I did not hit it frequently myself, so we can offer the env var as a temporary workaround for a bug that should be fixed.
I dont know much about s-b-i internals but i expect it will query lazily all possible info and only trigger update commands if needed, so it is supposed to trigger less that bug. In that case we will want to give it all possible info previously generated by the user so the default will have to be to share the same builddir, imo.
Fair enough, the configuration (and its interactions) can grow exponentially if we dont consider carefully additions. I would add the |
Yeah, that seems sensible to me, too.
True, but stuff like that already happens as the .hie and .hi files are located in |
Well, that files are not generated by cabal directly but they belongs to ghc, no? I think the problematic ones would be the generated directly by cabal ( Maybe i am being too cautious without real reasons so go ahead if you think it will be reliable enough. 😃 |
|
On Linux, I absolutely never have to execute |
|
cc @ndmitchell and @pepeiborra, since this change affects all IDE users. |
|
I am supportive of this change |
wz1000
changed the title
|
This should be ready now, please review again. |
|
Adding suppor for stack has another caveat: hie-bios is gonna ignore the We are using it as a workaround for some issues and this would fix it but i would not use it if user is using that field ( |
wz1000
changed the title
|
I have reverted the stack change, someone who uses it can pick it back up if they want. |
This reverts commit 604dfb0.
|
I'd love to have a Hackage release with this in. |
|
This is blocked on the current behaviour of ghcide/hls. With this PR, I am pretty sure, the issue is how we cache results in https://github.com/haskell/haskell-language-server/blob/master/ghcide/session-loader/Development/IDE/Session.hs#L122 but I got side-tracked by the holidays and so on. A fix could be to maintain an additional cache for all FilePaths to their respective ComponentOptions directly. I plan to get back to it this weekend. |
Achieves this by adding a HashMap from NormalizedFilePath to its respective hie.yaml location. This works nicely with the existing implementation, but increases the memory usage by an considerable amount. This change is motivated by haskell/hie-bios#264 where we set the build-dir for cabal based projects to some config directory in order to avoid recompilation issues whenever users invoked `cabal build`. However, this uncovered an issue in the existing code-base, as HLS will ask for the compilation options for generated modules, such as `Paths_*`, by looking for the responsible `hie.yaml` file and using an internal cache for the options. This used to be fine, until the aforementioned hie-bios change, since now `Paths_*` module will be in some `~/.cache/hie-bios/...` directory, which has no responsible `hie.yaml` which is why we see error messages such: `No hie.yaml found, use implicit hie-bios`.
Achieves this by adding a HashMap from NormalizedFilePath to its respective hie.yaml location. This works nicely with the existing implementation, but increases the memory usage by an considerable amount. This change is motivated by haskell/hie-bios#264 where we set the build-dir for cabal based projects to some config directory in order to avoid recompilation issues whenever users invoked `cabal build`. However, this uncovered an issue in the existing code-base, as HLS will ask for the compilation options for generated modules, such as `Paths_*`, by looking for the responsible `hie.yaml` file and using an internal cache for the options. This used to be fine, until the aforementioned hie-bios change, since now `Paths_*` module will be in some `~/.cache/hie-bios/...` directory, which has no responsible `hie.yaml` which is why we see error messages such: `No hie.yaml found, use implicit hie-bios`.
Achieves this by adding a HashMap from NormalizedFilePath to its respective hie.yaml location. This works nicely with the existing implementation, but increases the memory usage by an considerable amount. This change is motivated by haskell/hie-bios#264 where we set the build-dir for cabal based projects to some config directory in order to avoid recompilation issues whenever users invoked `cabal build`. However, this uncovered an issue in the existing code-base, as HLS will ask for the compilation options for generated modules, such as `Paths_*`, by looking for the responsible `hie.yaml` file and using an internal cache for the options. This used to be fine, until the aforementioned hie-bios change, since now `Paths_*` module will be in some `~/.cache/hie-bios/...` directory, which has no responsible `hie.yaml` which is why we see error messages such: `No hie.yaml found, use implicit hie-bios`.
Achieves this by adding a HashMap from NormalizedFilePath to its respective hie.yaml location. This works nicely with the existing implementation, but increases the memory usage by an considerable amount. This change is motivated by haskell/hie-bios#264 where we set the build-dir for cabal based projects to some config directory in order to avoid recompilation issues whenever users invoked `cabal build`. However, this uncovered an issue in the existing code-base, as HLS will ask for the compilation options for generated modules, such as `Paths_*`, by looking for the responsible `hie.yaml` file and using an internal cache for the options. This used to be fine, until the aforementioned hie-bios change, since now `Paths_*` module will be in some `~/.cache/hie-bios/...` directory, which has no responsible `hie.yaml` which is why we see error messages such: `No hie.yaml found, use implicit hie-bios`.
Achieves this by adding a HashMap from NormalizedFilePath to its respective hie.yaml location. This works nicely with the existing implementation, but increases the memory usage by an considerable amount. This change is motivated by haskell/hie-bios#264 where we set the build-dir for cabal based projects to some config directory in order to avoid recompilation issues whenever users invoked `cabal build`. However, this uncovered an issue in the existing code-base, as HLS will ask for the compilation options for generated modules, such as `Paths_*`, by looking for the responsible `hie.yaml` file and using an internal cache for the options. This used to be fine, until the aforementioned hie-bios change, since now `Paths_*` module will be in some `~/.cache/hie-bios/...` directory, which has no responsible `hie.yaml` which is why we see error messages such: `No hie.yaml found, use implicit hie-bios`.
* Add custom cache layer for session loading Achieves this by adding a HashMap from NormalizedFilePath to its respective hie.yaml location. This works nicely with the existing implementation, but increases the memory usage by an considerable amount. This change is motivated by haskell/hie-bios#264 where we set the build-dir for cabal based projects to some config directory in order to avoid recompilation issues whenever users invoked `cabal build`. However, this uncovered an issue in the existing code-base, as HLS will ask for the compilation options for generated modules, such as `Paths_*`, by looking for the responsible `hie.yaml` file and using an internal cache for the options. This used to be fine, until the aforementioned hie-bios change, since now `Paths_*` module will be in some `~/.cache/hie-bios/...` directory, which has no responsible `hie.yaml` which is why we see error messages such: `No hie.yaml found, use implicit hie-bios`. * Apply suggestions from code review modifyVar with evaluate Co-authored-by: Pepe Iborra <[email protected]> Co-authored-by: Pepe Iborra <[email protected]> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Should fix #195