-
-
Notifications
You must be signed in to change notification settings - Fork 389
Reenable -fghc-lib build #784
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
Comments
Created haskell#784 to restore it
* Drop macOS benchmarks * Drop macOS tests * Really exclude Windows 8.6.4 It occasionally becomes much slower than the others and times out after 6h https://github.com/haskell/haskell-language-server/runs/1626173853?check_suite_focus=true * switch to haskell/actions/setup actions/setup-haskell has been archived, haskell/actions/setup is the replacement * use coarser cache keys We are getting very few cache hits because we have too many caches and are running over the 5GB per repository limit. Each node in the matrix weighs around 350MB, so we can have up to 15 nodes. The current matrix (after dropping macOS but before adding 8.10.3) has 12 nodes. The `**/*.cabal` hash is wrong, since it also captures cabal files in tests The `**/cabal.project` is wrong for the same reason, but it can be easily fixed. * Use more precise .cabal paths in test cache * Reuse build cache in bench workflows and viceversa * Reduce Nix builds to the bare minimum We simply need to check that the Nix derivation works * remove enable-stack * Auto cancel redundant workflows * Enable tests fail-fast * Remove ghc-lib from matrix Created #784 to restore it
Not sure if we should remove ghc-lib support entirely, does daml still need it here? |
Indeed. |
CC @martin-drhu-da and @cocreature - do you have value in the ghc-lib target for HLS/Ghcide? If so, we should enable CI. If not, we should delete it. The middle ground is probably not useful for anyone. |
We still use ghcide via ghc-lib so in principle yes, there is value for us. However, we haven’t upgraded our ghcide base commit in ages (I think we’re on a commit from march 2013) so at this point, it seems unreasonable to ask you to keep supporting it just because we might upgrade at some point. Even if we do, we can probably maintain the ghc-lib specific changes in our fork. So my suggestion is to drop it even if it slightly pains me to say that. Thanks for keeping it so long! |
The ghc-lib build (using flag
ghc-lib
for theghcide
package) needs a test. 0db12a71 shows what is missing, but needs adjusting to build only ghcide and nothing else. Probably best to create a separate workflow for itThe text was updated successfully, but these errors were encountered: