Future of @rules_cc / @rules_java ?

26 views
Skip to first unread message

Lukács T. Berki

unread,
Sep 21, 2022, 6:16:34 AMSep 21
to Ivo Ristovski List, Yifan Hong, Matthias Männich, bazel-dev
Hey Ivo,

What is the plan for the future of @rules_cc / @rules_java ?

My understanding is that the long-term plan is for them to contain the Starlark implementation of C++/Java rules, but now they contain only placeholders that forward calls to the implementations within Bazel (Java or built in Starlark)

I thought removing the references to @rules_cc and @rules_java from the source code of Bazel itself would be pretty uncontroversial since we don't even have concrete long-term plans to actually move the code there and we are planning to rely on built-in Starlark for the time being, but you indicated that those plans already exist, which would make these repositories maybe not alive, but in the process of being thawed out.

My take on this is that I would like to be in either of these two situations:
  1. These repositories are alive and we have plans to make them work in the medium term. This requires figuring out how not to get version skew between Bazel and this repository and giving up the ability to change our Java code and the code in this repository atomically.
  2. They are zombies: we admit that we don't know how to move Starlark code to these repositories yet, so for now, the only plan we have is to use built-in Starlark code.
The scenario I'd like to avoid is that we are paying for this abstraction without any plan to actually benefit from it.

This is relevant because Yifan and Matthias ran into a dependency on these repositories and they are planning to vendor them, but if the outcome is (2), then that won't be necessary and then their lives are a bit simpler.

--
Lukács T. Berki | Software Engineer | lbe...@google.com | 

Google Germany GmbH | Erika-Mann-Str. 33  | 80636 München | Germany | Geschäftsführer: Paul Manicle, Halimah DeLaine Prado | Registergericht und -nummer: Hamburg, HRB 86891

Xudong Yang

unread,
Sep 21, 2022, 6:21:05 AMSep 21
to Lukács T. Berki, Pedro Liberal Fernandez, Ivo Ristovski List, Yifan Hong, Matthias Männich, bazel-dev
+Pedro Liberal Fernandez 

Also to note, @rules_cc lags behind @bazel_tools in certain aspects, so much that we had to stop using rules_cc toolchain discovery (see https://github.com/bazelbuild/bazel/commit/5d936d48b07b033cf6388a16f6639886ef87f514 and https://github.com/bazelbuild/bazel-central-registry/pull/90).

"  YÁNG Xùdōng (杨旭东)
#  SURNAME Givenname
=  Software Engineer
@  Google Munich


--
You received this message because you are subscribed to the Google Groups "bazel-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-dev/CAOu%2B0LUUZ%3DZhh%3DkgccAiSWv48Za6ysZJQOdTRz%3D%3DcDu%3DcHJL-g%40mail.gmail.com.

Ivo Ristovski List

unread,
Sep 21, 2022, 9:15:39 AMSep 21
to Xudong Yang, Lukács T. Berki, Pedro Liberal Fernandez, Yifan Hong, Matthias Männich, bazel-dev
You're right about the long-term plan, unfortunately you can't say they are either completely alive or completely dead, since they are in the process of thawing :( You certainly can't say they're dead.

We can't do a "door shut" approach in Bazel, we need to migrate things one problem at a time. The incompatibility I'm in the process of introducing is a requirement that what used to be top-level symbols in Bazel (like JavaInfo, cc_common) can only be used through their rightful repositories. This will need a migration of a "relatively small" set of repositories that are breaking these rules.

Another evidence the repositories are still required are buildifier warnings to load rules from these repositories.

I don't want to tell the users with the next LTS or one after - "sorry all top-level symbols and rules are gone - please migrate to use the new release".

The decision if you want to use rules_java and rules_cc is still yours. If you only need rules (not modules or providers) and want to ignore buildifier warnings, feel free to use them directly. The warning is that the migration is going to get harder with time.

About lagging - we need to fix those. And we need to stop putting everything into bazel_tools, just because it's cosy.

-- Ivo
--

Ivo List | Software Engineer | il...@google.com | 

Lukács T. Berki

unread,
Sep 22, 2022, 8:11:40 AMSep 22
to Ivo Ristovski List, Xudong Yang, Pedro Liberal Fernandez, Yifan Hong, Matthias Männich, bazel-dev
Okie. What I'm hearing is that you are in the process of increasing the requirement to use @rules_cc / @rules_java in Bazel and thus these repositories should be vendored where Bazel is used; it's a good long-term plan because I don't like these random top-level symbols, either and these repositories are their natural place.

(arguing that Buildifier is the authority is kinda weird, though, because Buildifier should do what our policy is and not the other way round)

@Matthias: then I guess vendoring it is? Let me know if it causes undue burden to you, we'll figure something out.



 
Reply all
Reply to author
Forward
0 new messages