To support runfiles, the rule has to track more than just the
executable. `files_to_run` has both the runfile and executable
information (as separate fields), as does `files`, (combined as depset).
So using those when able is inherently "safe." `files_to_run.executable`
is only the executable, so does not propagate dependency information,
so we make sure to pass `files` to the rule in addition.
(`files_to_run.executable` is formatted into a string, so it wouldn't
carry depset information anyway.)
As originally noticed in cl/597962426
While not easy to use because java_grpc_library() uses a fixed
toolchain, it is possible for downstream users to apply a patch to the
repo to add their own annotation processors. This feature was added
inside Google so exporting it reduces the diff between internal and
external and causes no harm.
cl/280287611
Replace ctx.host_configuration.host_path_separator with ctx.configuration.host_path_separator.
This is because
1. we're removing ctx.host_configuration
2. host_path_separator's value doesn't depend on the configuration (the API is misleading by embedding it under ctx.configuration). So this is a no-op.
Internal ref cl/494008561.
This change migrates from `cfg = "host"` to `cfg = "exec"`.
This is a no-op cleanup: `cfg = "host"` is a deprecated alias
for `cfg = "exec"`.
Tested:
```
bazel build //grpclb:grpclb
bazel build //compiler:java_grpc_library_toolchain
bazel build //compiler:grpc_java_plugin
bazel build '//compiler:*'
```
Internal ref cl/487924699
If protoc is compiled with MinGW it will depend on libstdc++-6.dll which is found in C:\msys64\mingw64\bin and can only be found by inheriting PATH from the environment.
Parameter host_javabase is removed.
This is preparation for flipping incompatible_java_common_parameters in
Bazel 5. See https://github.com/bazelbuild/bazel/issues/12373
Bazel versions prior to 4 require host_javabase, so are no longer supported.
These methods were used to migrate the Java toolchains to use toolchain
resolution. Now that the migration is complete, the toolchain providers
can be used directly.
In addition to this welcome functionality, this change also makes it
possible to fix http://github.com/bazelbuild/bazel/issues/7157 by
tolerating proto_library rules using a virtual import directory.
Depending on jdk:toolchain causes java_grpc_library to always use the
_default_ toolchain, even if the user tried to override it. Changing to
:current_java_toolchain allows the rule to use the user-selected
toolchain when overridden.
Tested by adding to BUILD:
load("@bazel_tools//tools/jdk:default_java_toolchain.bzl", "default_java_toolchain")
default_java_toolchain(
name = "mychain",
misc = ["-Amy=flag"],
visibility = ["//visibility:public"],
)
And then verifying -Amy=flag is in the output of:
bazel aquery --java_toolchain=:mychain services:_reflection_java_grpc
Fixes#5841
This removes the "java_import to work around error with android_binary"
hack; see the b/78647825 references to see the really important parts.
But in general using a toolchain cleans up the code considerably and
allows us to reduce the visibility of our protoc plugin. It also is
useful to enable using aspects in the future to avoid using
make_non_strict() which would improve compilation speed avoid avoid many
unnecessary rebuilds.
This is an export of cl/229763103 and brings external up-to-sync with
internal.
Also pass in the binary correctly as a tool. This is required for #5383.
I have tested the build with older Bazel versions and this doesn't
appear to affect compatibility, ie grpc-java continues to be compatible
with Bazel >=0.19.
This is a sync from our internal copy, so has lots of small changes.
But the most important change is strict_deps issues are worked around
within the rule. This means there should be no longer any reason to
specify more than one dep.
Our Bazel CI is still on Bazel 0.20, so for the moment avoid requiring
Bazel 0.22 by staying on the old 'proto' provider instead of ProtoInfo.
Fixes#5314
gRPC's protobuf-lite auto-selects between full and lite protobuf based on the
value of crosstool_top. If the user is specifying their own
--android_crosstool_top, then it will not auto-detect correctly. One day,
platforms will fix problems like this, but for the moment it seems we get to
live with it.
They were removed in 137c74d1 since it was believed they were unnecessary.
However, since they are in a macro and not a rule, they are relative to the
caller, not their definition.
Added building the examples to the kokoro CI. Note that this means the examples
are built twice: once in grpc-java's build and once in their own (because it
has a WORKSPACE). Given that the Bazel build is our fastest build, this
slowdown won't probably be an issue.
This was deprecated with Bazel 0.8.0, which now uses
@com_google_protobuf instead.
This change will break users that use
grpc_java_repositories(omit_com_google_protobuf_java=True), so I've
added a custom error message to make the resolution clearer.
_path_ignoring_repository munges bazel filesystem paths into proto
import paths, in order to pass to protoc -I. Currently, the function
assumes that the include's path begins with the bazel workspace root,
which can therefore be sheared off the front of the path.
This assumption is incorrect. For an include living in an external
repository (say, `@com_google_protobuf//:timestamp_proto`),
the filesystem path is something like
`bazel-out/darwin_x86_64-fastbuild/genfiles/external/com_google_protobuf/google/protobuf/timestamp.proto`.
(See also:
http://docs.bazel.build/versions/master/skylark/lib/Label.html#workspace_root.)
This commit changes _path_ignoring_repository to handle this case correctly.
This commit aligns the naming of the Bazel Maven jars with the names
used by Bazel's migration-tooling project:
https://github.com/bazelbuild/migration-tooling
Unfortunately, we can't fix @com_google_protobuf_java because it's
required by Bazel itself.
Fixes#3328
Bazel third party dependencies are specified in repositories.bzl which
gives the consumer the ability to opt-out of any dependencies they use
directly in their own project.
Fixes#2756
hvadehra