When both directories are added this results in protoc emitting a
"warning: directory does not exist.". This makes sense because when
there are no inputs from the other directory, it is also not present
n the sandbox where protoc is executed.
* Use repo-relative labels wherever possible
The label `@com_google_protobuf//:foo` within the protobuf repo is often synonymous with just `//:foo`. We should prefer the latter as it allows us to use a shorter name for the module in the Bazel Central Registry (so just "protobuf" instead of "com_google_protobuf").
Note that the semantics can be subtle: in a macro, plain strings are anchored to the *calling* repo, so if we just use `//:foo` as the default value of a macro argument, it will be resolved to `@myrepo//:foo` if the macro is called from the repo `@myrepo`. In this case, it's necessary to directly call the `Label()` constructor to anchor the string label to the repo where the .bzl file lives.
See https://github.com/bazelbuild/bazel-central-registry/pull/28#issuecomment-954741081 for a bit more context.
* fix protobuf_deps.bzl
Bazel has switched its protobuf rules to make them use the proto
compiler in the exec configuration instead of the host configuration.
However, if rules in protobuf still use the host configuration then
multiple copies of the compiler can end up being built.
cfg="host" is deprecated in any case and being replaced with cfg="exec"
where possible.
https://docs.bazel.build/versions/master/skylark/rules.html#configurations
* Protobuf Java/Core Tests running w/ Bazel.
Also integrates rules_jvm_external and migrates existing maven deps
in place.
* Add test_suite target that maps to rule name.
* Lite tests passing in Bazel
* util tests passing with Bazel.
* Add conformance and build testing to //java:core
* Cleanup bzl style and lock down access to failure lists.
* Adding Java Lite conformance tests.
* rm newline
* parameterize conformance_test
This makes usage of failure lists more explicit.
* restrict visibility more for newly added libs and fix formatting.
* fix formatting and visibility.
* move testing.bzl to an internal package.
* fix file formatting.
* moving conformance_test to internal.bzl
We may need the shell environment (potentially augmented with
`--action_env`) to invoke protoc on Windows. If protoc was built with
mingw, it probably needs .dll files in non-default locations that must be
in PATH. Previously with `--compiler=mingw-gcc`,
`bazel build //:gen_well_known_protos_java` would fail on Windows. This
CL fixes the issue.
Also we have `default_shell_env` set to True for `ProtoCompile`, this makes
the behavior consistent.
See #2933, and
585a27ad0a/proto/compiler.bzl (L130)
* [bazel] Move Java runtime/toolchains into //java
This change moves `java_library` targets from the top-level BUILD file
into `//java/{core,lite,util}` and declares `alias` targets to point to
their new locations (hence, this is not a breaking change).
This will allow users that don't use Java to stop depending on
`@rules_java` (e.g. as requested in
https://github.com/bazelbuild/rules_scala/pull/989#issuecomment-583405161).
Note that there is no intention to deprecate + remove the top-level
targets in the foreseeable future.
* Add BUILD files in //java to java_EXTRA_DIST
This change adds the required loads to examples and zlib.
For full compatibility with --incompatible_load_{cc,java,proto}_rules_from_bzl,
we will need to roll gtest to a newer version.
@bazel_skylib//:lib is supposedly deprecated. The 'versions' struct in lib.bzl was committed to bazel-skylib at the same time as //lib:versions.bzl, so there should be no backward incompatibility.
@com_google_protobuf prefixed versions. This allows them to work in 3rd party
repositories.
Fix a bad visibility rule. :hidden does not exist, but :private does.
I am adding default shell environment, so that protobuf compilation makes use of set
LD_LIBRARY_PATH and so on.
In this way, also non-default gcc installations (e.g. not in /usr/lib) can be used to compile protobuf.
This would fix the following issue:
https://github.com/bazelbuild/bazel/issues/2515
Bazel is changing the way the execution root is organized (see https://github.com/bazelbuild/bazel/issues/1681
for details) and this updates the protobuf path logic to work with both old
and new versions of Bazel.
ctx.executable.plugin must be in the inputs of protoc's action when using a plugin, otherwise the action will fail.
This bug has been hidden by a bug in Bazel: for every ctx.action, Bazel used to automatically add the runfiles of all executable inputs of the RULE instead of using the inputs of the specific ACTION. Consequently, we could get away with underspecifying the inputs of the action.
FaBrand
Derek Perez
Mike Kruskal
Adam Cozzette
Deanna Garcia
Ivo List
Xùdōng Yáng
Joshua Haberman
Charles Mita
Adam Yi
Harvey Tuch
listonjesse
Yannic Bonenberger
Brian Wignall
Benjamin Peterson
Keith Smiley
Paul Yang
Jon Brandvein
Roger Chen
James Judd
Ittai Zeidman
Fahrzin Hemmati
Fahrzin Hemmati
Mateusz Matejczyk
James O'Kane
Jingwen Chen
Vladimir Moskva
Marco A. Harrendorf
cgrushko
Kristina Chodorow
Yunlong Liu
Wiktor Tomczak
Florian Weikert
Vladimir Moskva
Andreas Bergmeier