Conversation
Previously, the build failed to load on M1 computers because Coursier failed to fetch Java home for JVM version 8. Now, we force Coursier to use amd64 instead of aarch64. This may result in slightly slower builds, but it's a big improvement by the fact that the build loads and works correctly now.
|
Checking in a binary file for |
varungandhi-src
left a comment
There was a problem hiding this comment.
I don't really have anything substantive to add over the fact that it seems a little weird to have a coursier binary here; I'm guessing you must have a good reason for it.
|
The Coursier binary is intentionally embedded in the repo. The binary was updated to pull in the fix from the PR coursier/coursier#2489 It's not ideal to check in binaries but it's not a big problem IMO. I suppose we could write a bash script to |
|
Do users build the JAR from source or download a pre-built one? I guess I'm missing the link between "this is in the JAR" vs "this is checked in with the source code." |
|
Nothing is built from source. The Coursier launcher (the checked in binary) is a pre-built jar, and when you execute it Coursier downloads more pre-built jars from the internet. Coursier is a bit like npm/yarn but it can also manage Java installations. We use both features in scip-java, we use Coursier to run tests across different Java versions and we also use Coursier to download dependencies from Maven Central in the snapshot tests (also when we run |
Previously, the build failed to load on M1 computers because Coursier
failed to fetch Java home for JVM version 8. Now, we force Coursier to
use amd64 instead of aarch64. This may result in slightly slower builds,
but it's a big improvement by the fact that the build loads and works
correctly now.
This PR was enabled by the new
--architectureflag that I contributed toCoursier 2 weeks ago https://github.com/coursier/coursier/pull/2489/files
Test plan
Manually loaded the build on my local M1 computer. We don't run the test suite on M1 chips in CI yet.