46290f5338
jni_zero generated proxy classes depend on classes defined by the user, e.g. jni_zero will generate proxy classes of the form: class FooJni implements Foo.Natives Where `Foo` is a user-defined class. This means that jni_zero generated proxy classes will not compile on their own - they need to built alongside some definition of the user classes. Up until now this wasn't a problem because all usages of jni_zero in Cronet involved compiling the jni_zero proxy classes in the same GN target as the user classes, so they could always find each other. For example, //components/cronet:cronet_impl_native_java operates this way. However, the world has changed with https://crrev.com/c/6217929, which makes use of autogenerated standalone jni_zero java_library targets (e.g. //base:command_line_jni_java) that only contain the proxy classes. The way this works is: 1. The jni_zero generator action generates placeholder (stub) user classes with a compatible interface; 2. The standalone jni_zero java_library target is built against these placeholder classes; 3. The placeholder classes are then removed from the compiled output jar (so that they don't conflict with the "real" classes later on), leaving only the proxy classes; 4. The "real" classes are then built against the compiled proxy classes. Up until this CL, this did not work in gn2bp because gn2bp simply did not support jni_zero placeholders - they were dropped from the output of the jni_zero generator genrule. Fixing this is not as simple as it sounds because, if we naively just output the placeholders from the jni_zero genrule, they will end up as inputs of modules that also take the real classes as sources (e.g. //components/cronet:cronet_impl_native_java), leading to duplicate class errors. To avoid this problem, we need gn2bp to understand when a target depends on the placeholders, as opposed to just the proxies. If it only pulls the proxies, it is imperative that we do not pull the placeholders along with them. Which is, once again, not as simple as it sounds, because Soong does not support only pulling a subset of outputs from a genrule. We work around this limitation by introducing an intermediate genrule that takes in the output of the jni_zero generator genrule and strips the placeholders. Bug: b:397396295 Change-Id: I9012e450a3bc30a16b80fb8507ed263d29d5efc0 Cq-Include-Trybots: luci.chromium.try:android-cronet-arm64-gn2bp-dbg Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6330112 Reviewed-by: Mohannad Farrag <aymanm@google.com> Commit-Queue: Etienne Dechamps <edechamps@google.com> Cr-Commit-Position: refs/heads/main@{#1431010}
v8
@ a76ae4f192
Chromium
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
The project's web site is https://www.chromium.org.
To check out the source code locally, don't use git clone! Instead,
follow the instructions on how to get the code.
Documentation in the source is rooted in docs/README.md.
Learn how to Get Around the Chromium Source Code Directory Structure.
For historical reasons, there are some small top level directories. Now the guidance is that new top level directories are for product (e.g. Chrome, Android WebView, Ash). Even if these products have multiple executables, the code should be in subdirectories of the product.
If you found a bug, please file it at https://crbug.com/new.