-
Notifications
You must be signed in to change notification settings - Fork 71
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
Add support for running weeder #132
Labels
Comments
mergify bot
pushed a commit
to swarm-game/swarm
that referenced
this issue
Jul 17, 2024
Closes #2043 # Local usage notes I suspect that HLS in VS Code spontaneously pollutes the `.hie` directory, because after a few successful invocations, `weeder` started complaining with: ``` incompatible hie file: /home/kostmo/github/swarm/.hie/Swarm/Web/Auth.hie this version of weeder was compiled with GHC version 9064 the hie files in this project were generated with GHC version 9048 weeder must be built with the same GHC version as the project it is used on ``` ## Fixing false positives Previously, for each `library` and `executable`, the HIE directory was always the same: ``` ghc-options: -hiedir=.hie ``` However, most of the executables have at least one module path that is the same relative to their `hs-source-dirs` base: namely, `Main.hs`. This resulted in all but one of the `Main.hie` files being overwritten in the end. To avoid this, I have specified a different `-hiedir` for each `library`/`executable`/`test` that parallels its `hs-source-dirs` base. This way, so long as `hs-source-dirs` are unique across these targets, all of the `*.hs` files across the entire project will have unique `*.hie` paths. ## Whitelisting exceptions There are some known limitations with `weeder` regarding support for Template Haskell and type families. Exceptions are specified in the `roots` list in `weeder.toml`. After removing a handful of dead functions myself, there are approx. 30 "true positive" weeds that I have listed explicitly in `weeder.toml`. Maintenance of this list of exceptions should eventually be easier with ocharles/weeder#146. # Integration with CI I found a ready-made GitHub Action for weeder: https://github.com/freckle/weeder-action I hacked support directly into the generated `.github/workflows/haskell-ci.yml` file. Ideally, the generator would have an option for a `weeder` step. Indeed, there is an open issue for supporting `weeder` in `haskell-ci`: haskell-CI/haskell-ci#132 A separate but related functionality that would be nice in `haskell-ci` is to specify **one** of the GHC versions in the matrix to do additional validations/builds that would be redundant if performed on the other matrix entries. I suppose `weeder` is inexpensive enough to redo four times, but the `weeder` binary is not available for download for all GHC versions (e.g. ghc `9.8.2`). Something like `haddock` we probably only need to build once. I have hacked this in to the generated file for `weeder` with a simple [`if` condition](https://github.com/swarm-game/swarm/pull/2044/files#diff-73f8a010e9b95aa9fe944c316576b12c2ec961272d428e38721112ecb1c1a98bR227).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
http://hackage.haskell.org/package/weeder is very useful at catching over-specified build-dependencies etc., and it would be nice to have support for running it on travis-ci automatically. Unfortunately, weeder is currently very much tied to
stack
. I suppose that's going to change eventually, though, it's only a matter of time until someone figures out how to supportcabal-install
properly.The text was updated successfully, but these errors were encountered: