Conversation
|
LGTM. Are the examples automatically tested, or would an explicit test be needed to make sure this works in CI? |
| @@ -0,0 +1,6 @@ | |||
| # Not ready for the MODULE.lock file yet, as of Bazel 7.0.0 there are still some stability issues. | |||
| common --lockfile_mode=off | |||
There was a problem hiding this comment.
nit: it's better to gitignore it instead. You can get some perf benefits locally by Bazel reading the lockfile from your previous work, and not share it to others
| main = ":ruby_file", | ||
| ) | ||
|
|
||
| cc_library( |
There was a problem hiding this comment.
nit: there's some flag in bazel forcing these symbols to be loaded from a ruleset rather than using the now-deprecated native symbols. If a user turns on that flag I think this will be broken for them.
There was a problem hiding this comment.
Yeah, we should probably use rules_cc: https://blog.bazel.build/2024/12/09/bazel-8-release.html#starlarkification-modularization-of-rules.
There was a problem hiding this comment.
I've added an explicit dependency on rules_cc and rules_java in 0f52ccb, I hope that makes sense. Not sure what is the lowest version I could use so I looked at what other rulesets use.
There was a problem hiding this comment.
I think this is OK but it feels a bit undesirable that you're forced into carrying these CC/Java toolchain deps even if you have no interest in using them. Don't have any good ideas to avoid it though.
There was a problem hiding this comment.
That's why I originally didn't add those and used native rules. @alexeagle Can you advise what would be better here?
There was a problem hiding this comment.
You don't really have a choice. This repo wants to expose the providers for interop with users repository, and providers are symbols rather than strings, so they have to be loaded from the same place.
We'll hope that rules_java and rules_cc are well-maintained so there aren't breaking changes that mean your users are sensitive to the version you pick. In bzlmod you can pick something old, since you're really picking a lower-bound; the MVS algorithm means users can still resolve to something newer.
There was a problem hiding this comment.
For both rulesets, I used > 1-year-old releases and crossed-check what other dependents do (e.g. rules_python, rules_kotlin).
| main = ":ruby_file", | ||
| ) | ||
|
|
||
| cc_library( |
There was a problem hiding this comment.
I think this is OK but it feels a bit undesirable that you're forced into carrying these CC/Java toolchain deps even if you have no interest in using them. Don't have any good ideas to avoid it though.
4 participants
Allows to use C headers on MRI to compile
cc_libraryand JRuby jars to compilejava_librarytargets.See examples/native_ext for examples.
Relates to #186.