-
Notifications
You must be signed in to change notification settings - Fork 0
Build and utilize pre-compiled binaries #4
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
Conversation
GHCs = %W[ | ||
9.2.5 | ||
9.2.4 | ||
9.2.3 | ||
9.2.2 | ||
9.0.2 | ||
9.0.1 | ||
8.10.7 | ||
8.10.6 | ||
8.10.5 | ||
8.10.4 | ||
8.10.3 | ||
8.10.2 | ||
8.10.1 | ||
8.8.4 | ||
8.8.3 | ||
8.8.2 | ||
8.8.1 | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side quest, would it make sense to contribute this matrix to weeder
itself and pull binaries from that project?
https://github.com/ocharles/weeder/releases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ocharles is using nix
, which makes binary caching easy, but I'm not sure the current state of multi GHC builds in that ecosystem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was indeed surprised when I found they weren't there. It's possible needing to have a binary built against the GHC of your project was enough complexity that they punted -- or maybe there's an Actual Reason they'd not want it. I'll probably open an Issue to ask at some point.
Making users wait for a `stack install weeder` is an unnecessary tax on every CI run that lacks a complete cache. Instead, this PR adds an "Binaries" action that builds binaries across a runner/GHC matrix and stores them on a Release for use by the action. The Binaries action is idempotent and has been run and added all the binaries already, which our own CI uses successfully. I made binaries for Linux and Mac and GHCs 8.8.1 to 9.2.5. Windows may be possible, but the `prep` step needs to be rewritten for that platform. These are all the GHC versions for which a released version of `weeder` exists, so it should cover all users. Arguably, these binaries should be released by the weeder project itself. I may open an Issue soon to see if they'd be open to upstreaming something like tooling I have here, which is pretty non-standard due to the need to version by GHC and not by weeder.
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dope
Making users wait for a
stack install weeder
is an unnecessary tax onevery CI run that lacks a complete cache. Instead, this PR adds an
"Binaries" action that builds binaries across a runner/GHC matrix and
stores them on a Release for use by the action. The Binaries action is
idempotent and has been run and added all the binaries already, which
our own CI uses successfully.
I made binaries for Linux and Mac and GHCs 8.8.1 to 9.2.5. Windows may
be possible, but the
prep
step needs to be rewritten for thatplatform. These are all the GHC versions for which a released version of
weeder
exists, so it should cover all users.Arguably, these binaries should be released by the weeder project
itself. I may open an Issue soon to see if they'd be open to upstreaming
something like tooling I have here, which is pretty non-standard due to
the need to version by GHC and not by weeder.