-
Notifications
You must be signed in to change notification settings - Fork 402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rust_binary does not produce link in bazel-bin #305
Comments
Running a build with With a1d8936:
With a1d8936 reverted:
and |
This is a weird impact of using configuration. @gregestren might know a bit more about that. I have some reserve about a1d8936 as it adds a configuration that seems to be a host configuration which would explain why it is not in the good output. |
It appears to be something with how Bazel handles any translation added to the def _noop_transition(settings, attr):
return settings
noop_transition = transition(
implementation = _noop_transition,
inputs = [],
outputs = [],
) Perhaps there should be a different approach than transitions? |
Without digging too deeply into this, also note this flag: which resolves this problem as long as all targets use the same transition. If not all targets use the same transition we run into fundamentally harder issues described in https://docs.google.com/document/d/1fZI7wHoaS-vJvZy9SBxaHPitIzXE_nL9v4sS4mErrG4/edit |
This mostly reverts commit a1d8936, removing the proc_macro_host_transition from most rules. This fixes bazelbuild#305, by no longer having a transition on rust_binary. It still solves bazelbuild#300 by adding this transition to rust_proto_library and rust_grpc_library. Those rules are meant to mirror rust_library, so they should share the same cfg values. Sharing the same configuration means that rust_proto_library or rust_grpc_library can be dependencies to rust_library or rust_binary and not cause another configuration of the library to be generated. The example introduced by bazelbuild#301 is moved in this commit into a subfolder to provide a more clear directory structure.
This mostly reverts commit a1d8936, removing the proc_macro_host_transition from most rules. This fixes #305, by no longer having a transition on rust_binary. It still solves #300 by adding this transition to rust_proto_library and rust_grpc_library. Those rules are meant to mirror rust_library, so they should share the same cfg values. Sharing the same configuration means that rust_proto_library or rust_grpc_library can be dependencies to rust_library or rust_binary and not cause another configuration of the library to be generated. The example introduced by #301 is moved in this commit into a subfolder to provide a more clear directory structure.
My commit a1d8936 caused rust_binary to no longer link into bazel-bin. The binary still is built, and can be run by bazel run, but the binary no longer appears in bazel-bin, just bazel-out. This doesn't appear to be related to depending on a proc-macro, as the following example has this behavior.
Still trying to track down the exact cause of it here, but wanted to flag it in case anyone has noticed this behavior, or similar, and if it's more clear to others as to why this would happen.
Also, I'm not sure what the revert policy is for this project, but I'm perfectly fine reverting it until a fix is found. Let me know.
The text was updated successfully, but these errors were encountered: