AuroraMiddleware/protobuf
1
0
Fork 0
Code Issues 1 Pull Requests Projects Releases Wiki Activity
911c940569
protobuf/protobuf_deps.bzl

86 lines
3.7 KiB
Python
Raw Normal View History

create importable function for defining zlib
2019-02-26 18:07:55 +00:00
"""Load dependencies needed to compile the protobuf library as a 3rd-party consumer."""
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
Align dependency handling with Bazel best practices (#9165) This commit removes the use of bind() since that function goes against Bazel best practices: https://docs.bazel.build/versions/main/external.html#repository-rules-1 The bind() function basically maps a dependency into //external, but there is no good reason to do this. By mapping dependencies into //external and relying on this in our own BUILD files, we're forcing projects that depend on us to do the same. The one bind() call that I did leave in place was //:python_headers. This one seems to be doing something complicated I don't fully understand, and I don't want to risk breaking it. This change also moves our list of required Maven artifacts into a constant in protobuf_deps.bzl. This way, projects that depend on us can refer to this list when they invoke maven_install() and automatically pull in all the necesary dependencies. This fixes #9132.
2021-10-28 17:34:54 +00:00
PROTOBUF_MAVEN_ARTIFACTS = [
"com.google.code.findbugs:jsr305:3.0.2",
"com.google.code.gson:gson:2.8.6",
"com.google.errorprone:error_prone_annotations:2.3.2",
"com.google.j2objc:j2objc-annotations:1.3",
"com.google.guava:guava:30.1.1-jre",
"com.google.truth:truth:1.1.2",
"junit:junit:4.12",
"org.easymock:easymock:3.2",
]
create importable function for defining zlib
2019-02-26 18:07:55 +00:00
def protobuf_deps():
"""Loads common dependencies needed to compile the protobuf library."""
[bazel] Add fixes for --incompatible_load_{cc,java,proto}_rules_from_bzl (Part 2) 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.
2019-07-26 11:14:19 +00:00
if not native.existing_rule("bazel_skylib"):
http_archive(
name = "bazel_skylib",
[bazel] Fix blacklisted_protos in cc_toolchain and add test (#7075)
2020-01-15 18:27:35 +00:00
sha256 = "97e70364e9249702246c0e9444bccdc4b847bed1eb03c5a3ece4f83dfe6abc44",
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/bazel-skylib/releases/download/1.0.2/bazel-skylib-1.0.2.tar.gz",
"https://github.com/bazelbuild/bazel-skylib/releases/download/1.0.2/bazel-skylib-1.0.2.tar.gz",
],
[bazel] Add fixes for --incompatible_load_{cc,java,proto}_rules_from_bzl (Part 2) 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.
2019-07-26 11:14:19 +00:00
)
[bazel] Add fixes for --incompatible_load_{cc,java,proto}_rules_from_bzl
2019-07-23 14:28:57 +00:00
if not native.existing_rule("zlib"):
create importable function for defining zlib
2019-02-26 18:07:55 +00:00
http_archive(
comply with Bazel recommendations
2019-04-12 22:41:08 +00:00
name = "zlib",
Use repo-relative labels wherever possible (#9187) * 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
2021-11-04 14:56:32 +00:00
build_file = Label("//:third_party/zlib.BUILD"),
bazel: Change zlib URL to GitHub We've notice significant issues downloading from zlib.net. Since there are already other archives coming from GitHub, this shouldn't negatively affect reliability.
2019-08-29 04:41:02 +00:00
sha256 = "629380c90a77b964d896ed37163f5c3a34f6e6d897311f1df2a7016355c45eff",
create importable function for defining zlib
2019-02-26 18:07:55 +00:00
strip_prefix = "zlib-1.2.11",
bazel: Change zlib URL to GitHub We've notice significant issues downloading from zlib.net. Since there are already other archives coming from GitHub, this shouldn't negatively affect reliability.
2019-08-29 04:41:02 +00:00
urls = ["https://github.com/madler/zlib/archive/v1.2.11.tar.gz"],
create importable function for defining zlib
2019-02-26 18:07:55 +00:00
)
Fix usage of six in //:protobuf_python rule and add import (#6310) * Fix reference to six in //:protobuf_python rule * Add six to protobuf_deps.bzl * Use six archive directly as repo @six
2019-07-15 23:35:19 +00:00
[bazel] Add fixes for --incompatible_load_{cc,java,proto}_rules_from_bzl
2019-07-23 14:28:57 +00:00
if not native.existing_rule("rules_cc"):
http_archive(
name = "rules_cc",
Update rules_cc The previous version does not mark the `toolchain_type` as public, meaning that users of a CC toolchain using `@rules_cc//cc:toolchain_type` will get build errors along the lines of ``` ERROR: .../local_config_cc_toolchains/BUILD.bazel:18:1: in toolchain rule @local_config_cc_toolchains//:cc-toolchain-armeabi-v7a: alias '@rules_cc//cc:toolchain_type' referring to target '@bazel_tools//tools/cpp:toolchain_type' is not visible from target '@local_config_cc_toolchains//:cc-toolchain-armeabi-v7a'. Check the visibility declaration of the former target if you think the dependency is legitimate ```
2020-05-26 08:07:20 +00:00
sha256 = "9d48151ea71b3e225adfb6867e6d2c7d0dce46cbdc8710d9a9a628574dfd40a0",
strip_prefix = "rules_cc-818289e5613731ae410efb54218a4077fb9dbb03",
urls = ["https://github.com/bazelbuild/rules_cc/archive/818289e5613731ae410efb54218a4077fb9dbb03.tar.gz"],
[bazel] Add fixes for --incompatible_load_{cc,java,proto}_rules_from_bzl
2019-07-23 14:28:57 +00:00
)
if not native.existing_rule("rules_java"):
http_archive(
name = "rules_java",
sha256 = "f5a3e477e579231fca27bf202bb0e8fbe4fc6339d63b38ccb87c2760b533d1c3",
strip_prefix = "rules_java-981f06c3d2bd10225e85209904090eb7b5fb26bd",
urls = ["https://github.com/bazelbuild/rules_java/archive/981f06c3d2bd10225e85209904090eb7b5fb26bd.tar.gz"],
)
if not native.existing_rule("rules_proto"):
http_archive(
name = "rules_proto",
Use a newer version of rules_proto, with the new rule `proto_descriptor_set` (#8469)
2021-04-09 18:12:25 +00:00
sha256 = "a4382f78723af788f0bc19fd4c8411f44ffe0a72723670a34692ffad56ada3ac",
strip_prefix = "rules_proto-f7a30f6f80006b591fa7c437fe5a951eb10bcbcf",
urls = ["https://github.com/bazelbuild/rules_proto/archive/f7a30f6f80006b591fa7c437fe5a951eb10bcbcf.zip"],
[bazel] Load python rules from @rules_python
2019-08-06 19:12:06 +00:00
)
if not native.existing_rule("rules_python"):
http_archive(
name = "rules_python",
update rules_python dependency to version 0.1.0 (#8214) other bazel libraries (e.g. rules_docker 0.15.0) require rules_python 0.1.0 or above. running protobuf_deps() before importing rules_docker will lead to errors. upgrading rules_python fixes this problem.
2021-10-13 20:54:54 +00:00
sha256 = "b6d46438523a3ec0f3cead544190ee13223a52f6a6765a29eae7b7cc24cc83a0",
urls = ["https://github.com/bazelbuild/rules_python/releases/download/0.1.0/rules_python-0.1.0.tar.gz"],
[bazel] Add fixes for --incompatible_load_{cc,java,proto}_rules_from_bzl
2019-07-23 14:28:57 +00:00
)
Bazel powered Java testing (#8506) * 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
2021-04-20 18:36:32 +00:00
if not native.existing_rule("rules_jvm_external"):
Align dependency handling with Bazel best practices (#9165) This commit removes the use of bind() since that function goes against Bazel best practices: https://docs.bazel.build/versions/main/external.html#repository-rules-1 The bind() function basically maps a dependency into //external, but there is no good reason to do this. By mapping dependencies into //external and relying on this in our own BUILD files, we're forcing projects that depend on us to do the same. The one bind() call that I did leave in place was //:python_headers. This one seems to be doing something complicated I don't fully understand, and I don't want to risk breaking it. This change also moves our list of required Maven artifacts into a constant in protobuf_deps.bzl. This way, projects that depend on us can refer to this list when they invoke maven_install() and automatically pull in all the necesary dependencies. This fixes #9132.
2021-10-28 17:34:54 +00:00
http_archive(
Bazel powered Java testing (#8506) * 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
2021-04-20 18:36:32 +00:00
name = "rules_jvm_external",
Update rules_jvm_external to 4.1 (#8800)
2021-07-08 16:05:05 +00:00
sha256 = "f36441aa876c4f6427bfb2d1f2d723b48e9d930b62662bf723ddfb8fc80f0140",
strip_prefix = "rules_jvm_external-4.1",
urls = ["https://github.com/bazelbuild/rules_jvm_external/archive/4.1.zip"],
Bazel powered Java testing (#8506) * 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
2021-04-20 18:36:32 +00:00
)
Creates a protoc release zip (#9188) * Creates a protoc release zip Mimics what we're doing manually today but powered by Bazel. * don't special case this. * Addressing feedback. * adding comment about _cc_toolchain
2021-11-04 22:57:29 +00:00
if not native.existing_rule("rules_pkg"):
http_archive(
name = "rules_pkg",
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/rules_pkg/releases/download/0.5.1/rules_pkg-0.5.1.tar.gz",
"https://github.com/bazelbuild/rules_pkg/releases/download/0.5.1/rules_pkg-0.5.1.tar.gz",
],
sha256 = "a89e203d3cf264e564fcb96b6e06dd70bc0557356eb48400ce4b5d97c2c3720d",
)
Reference in New Issue Copy Permalink