Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hie-bios status in rules_haskell #1386

Closed
teto opened this issue Jul 2, 2020 · 6 comments
Closed

hie-bios status in rules_haskell #1386

teto opened this issue Jul 2, 2020 · 6 comments

Comments

@teto
Copy link
Contributor

teto commented Jul 2, 2020

I have 2 questions mostly:

The doc says

To set this up you can define a `haskell_repl`_ target that
will collect the required compiler flags for your Haskell targets and pass them
to `hie-bios`_ which will then forward them to ghcide.

but I believe latest hie-bios needs additionnal flags aka the modules (if I trust this comment: https://github.com/digital-asset/ghcide/issues/679#issuecomment-652258071)
does rules_haskell generate these too ? (doesn't seem like it in my test)

also I would like to install the hie-bios executable in my bazel repo (to be able to run hie-bios debug mostly). Is there a straightforward rules_haskell way ? or should I do it in my repo

cheers

@teto teto added the type: bug label Jul 2, 2020
@aherrmann
Copy link
Member

@teto Thank you for raising this. The ghcide documentation in rules_haskell indeed still targets an older version of ghcide before multi-cradle support was introduced. That ghcide version already used hie-bios version 0.5.0 but didn't yet forward the name of the current module to the bios cradle. Further details are discussed in the multi-cradle PR: haskell/ghcide#522 (comment). Some experiments on using multi-cradle ghcide in rules_haskell can be seen here.

@teto
Copy link
Contributor Author

teto commented Aug 13, 2020

also I've noticed a discrepancy between ghcide (which use hie-bios as documented by rules-haskell aka hie-bios calls bazel to get flags) and the plain bazel build. for instance some of the warnings in ghcide become errors when running bazel build etc. Has anyone noticed sthg similar ?

@aherrmann
Copy link
Member

The rules_haskell ghcide config will include REPL flags which regular builds don't include. So, if you've set any warning related config in repl_ghci_args this might be related. Similary, the docs recommend setting -Wwarn in the hie-bios script which will convert fatal warnings to non-fatal ones. Can you share an example of differences you are observing?

@teto
Copy link
Contributor Author

teto commented Aug 28, 2020

I have indeed the -Wwarn added. There is something I wanted to do, and I wonder if that's too specific. I want to generate a static multicomponent hie.yaml. The current hie-bios script relying on bazel can make ghcide slow sometimes so what I plan to do is to pipe the output of hie-bios for each component into a fully static hie.yaml for instance when entering the nix-shell.
Compared to the approach of always calling the bazel repl, it may get out of sync but it will also be faster. I don't think there is any way to integrate this in rules_haskell but I mention it in case you heard of a similar project ? I could share some doc/blog post if it's of interest.

@aherrmann
Copy link
Member

I want to generate a static multicomponent hie.yaml.

That's an interesting idea. You may need to work around issues with generated files as described in haskell/ghcide#522 (comment). AFAIK multi-cradle works on file paths, so I had to define a separate cradle for generated files in that example, since they appear under bazel-bin rather than in the project root.

You can use bazel build --output_groups=hie_bios //my:target (assuming that //my:target is a haskell_repl) to extract the plain flags.

The current hie-bios script relying on bazel can make ghcide slow sometimes so what I plan to do is to pipe the output of hie-bios for each component into a fully static hie.yaml for instance when entering the nix-shell.

It may be worth looking into when and why this is slow. Bazel should cache the hie_bios outputs in the output base and should also be able to cache them in the disk cache if enabled. Since #1389 the hie_bios outputs also contain the list of covered modules, so ghcide should only need to query hie-bios once per cradle. One possibility is that different Bazel flags passed in the .hie-bios script and build commands issued on the command-line invalidate the analysis cache and force Bazel to rebuild. To work around that you could either make sure the flags are identical, or configure a separate --output_base in the .hie-bios script.

I don't think there is any way to integrate this in rules_haskell but I mention it in case you heard of a similar project ?

I'm not aware of a project like this. There was some discussion about using hrepl for hie-bios integration, however that would still involve intermediate Bazel calls.

I could share some doc/blog post if it's of interest.

That would be great, yes!

@aherrmann
Copy link
Member

latest hie-bios needs additionnal flags aka the modules

This was addressed by #1389.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants