-
-
Notifications
You must be signed in to change notification settings - Fork 286
Cross building #80
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
I think this is similar to #14 I agree we should work on it. The ideal case is that we just point at different repositories and maybe some functions to get the particular version numbers out. We can certainly factor common code to something like I don't think it is too hard, I just have not taken a stab. Probably |
this could be a useful approach: #84 |
Indeed. I think one of the other rules uses it (rust? Go?)
|
#84 doesn't let you cross build, right? It just gives you a way to globally change the version? A couple more thoughts
|
I agree cross-building is somewhat interesting, but it is a very low priority for me personally. I'm happy to review PRs. Bazel is generally used for private (logical) monorepos. There is no support for publishing, for instance. We could have multiple parallel builds, or we could say that the cross building solution is to have your CI bump the scala version you are using. At Twitter, where we used the similar pants build system, there was no support for this, and in general keeping a large monorepo green with more than one version of scala, I think will be very challenging, not to mention tooling to support versioning the external jars correctly, something bazel does not understand (that scala has multiple parallel artifacts for each different release of scala). |
see #251 |
Checking in if this is something that will be supported. Otherwise, in order for us to adopt Bazel, we'll have to get all of our services on the same Scala version (which isn't ideal). |
I think this thread is still the state of the art. You can switch scala versions and so you can manage to have your CI set two different versions, but having a two versions in the same build is not yet supported. It sounds like you want to build some parts of the code with only version A and others with one version B. Is that right? A key challenge is this: we want to support interoperability with java (java can depend on scala). But we can’t add two versions of the scala library on the class path. So we need some way to error if that happens. I don’t think we have found a design where multiple versions of scala in the same build in bazel works great. |
SGTM, thanks for the tip on the CI switch |
I wonder what Databricks did internally to support |
Wrote a blog post cross build anything with Bazel documenting the stateful cross building (aka switch at CI approach). |
So this isn't anything urgent but popped into my head and thought it would be best to start the conversation now before 2.12 is released and we might have more pressure.
2 questions:
The text was updated successfully, but these errors were encountered: