|
1 | 1 | # load("@rules_proto//proto:defs.bzl", "proto_library")
|
2 | 2 | # load("@io_bazel_rules_rust//proto:proto.bzl", "rust_proto_library")
|
3 | 3 | # load("@io_bazel_rules_rust//proto:toolchain.bzl", "PROTO_COMPILE_DEPS", "rust_proto_toolchain")
|
4 |
| -load("@io_bazel_rules_rust//rust:rust.bzl", "rust_library", "rust_binary") |
| 4 | +load("//rust:rust.bzl", "rust_no_worker_library", "rust_no_worker_binary") |
5 | 5 |
|
6 |
| -rust_library( |
| 6 | +rust_no_worker_library( |
7 | 7 | name = "rustc_worker",
|
| 8 | + edition = "2018", |
8 | 9 | srcs = [
|
9 | 10 | "src/lib.rs",
|
10 | 11 | "src/worker_protocol.rs",
|
11 | 12 | ],
|
12 | 13 | deps = [
|
13 |
| - "@io_bazel_rules_rust//proto/raze:protobuf", |
| 14 | + "//proto/raze:protobuf", |
14 | 15 | ],
|
15 | 16 | )
|
16 | 17 |
|
17 |
| -rust_binary( |
| 18 | +rust_no_worker_binary( |
18 | 19 | name = "rustc-worker",
|
| 20 | + edition = "2018", |
19 | 21 | srcs = ["src/main.rs"],
|
20 | 22 | deps = [
|
21 | 23 | ":rustc_worker",
|
22 |
| - "@io_bazel_rules_rust//proto/raze:protobuf", |
| 24 | + "//proto/raze:protobuf", |
23 | 25 | ],
|
| 26 | + visibility = ["//visibility:public"], |
24 | 27 | )
|
25 | 28 |
|
26 |
| -# rust_proto_toolchain(name = "default-proto-toolchain-impl") |
27 |
| -# |
28 |
| -# toolchain( |
29 |
| -# name = "default-proto-toolchain", |
30 |
| -# toolchain = ":default-proto-toolchain-impl", |
31 |
| -# toolchain_type = "@io_bazel_rules_rust//proto:toolchain", |
32 |
| -# ) |
33 |
| -# |
34 |
| -# proto_library( |
35 |
| -# name = "worker_protocol_proto", |
36 |
| -# srcs = ["src/worker_protocol.proto"], |
37 |
| -# ) |
38 |
| -# |
39 |
| -# rust_proto_library( |
40 |
| -# name = "worker_protocol", |
41 |
| -# deps = [":worker_protocol_proto"], |
42 |
| -# ) |
| 29 | +# The rust_* rules are required to build the worker |
| 30 | +# They shouldn't _use_ the worker when building the worker OR any of its dependencies |
| 31 | +# Ideally we want some transitive switch applier (like a custom transition?) that will enforce this across the entire dependency graph. |
| 32 | +# What does that look like? |
| 33 | +# Can we use transitions? Is that supported in Bazel 0.27? |
| 34 | +# Alternatively can we use a config-setting? |
| 35 | +# In that case, how do we enforce the config setting when building the worker? |
| 36 | +# Alternatively, we would need to make raze emit customizable rule names, then have it run in the custom mode to generate the BUILD files for the protobuf bits. |
| 37 | + |
| 38 | +# On the C++ side, the protobuf repo does provide a "protobuf" and "protobuf-lite" target to link the worker against, that will allow us to use protobufs easily. |
| 39 | + |
| 40 | +# we would need to write code to repeatedly execute the child process and capture stdout. |
| 41 | +# similarly, we would need to write code to parse args (actually that exists). |
| 42 | +# we would need some equivalent of canonicalize (realpath on unix, GetFinalPathNameByHandle on windows), |
| 43 | +# response file handling and reading |
| 44 | +# hashing the inputs |
| 45 | +# mkdir_all |
| 46 | + |
| 47 | +# otherwise edit the raze files... |
0 commit comments