-
Notifications
You must be signed in to change notification settings - Fork 406
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
Support expanding locations in rustc_env and build_script_env #461
Closed
Closed
Changes from 2 commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
f3d1552
$(location ...) expansion and runtime data support for build scripts
dae e37b492
rely on build script to locate bazel-out parent
dae 6f5dbca
add test for source file access as well
dae 41484f5
add run_in_execroot flag to cargo_build_script()
dae 14e4b8b
Regenerate documentation
dae cb10fec
add note about build_script_env being preferable for build scripts
dae 95fd967
prepend execroot automatically in build script runner
dae 8158d14
Regenerate documentation
dae 362b166
add back accidentally removed deps in build script run
dae File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this general change of allowing
location
expansion is a really useful one, but I don't love the interactions around path lookups.In particular, this suggestion to traverse parent directories until you happen to find the right one. The
bazel-out
heuristic is an internal implementation detail of how bazel lays out files, and actually only happens to be true for generated files - if you did$(execroot //some/checked/in:file)
there wouldn't be abazel-out
.$(location)
and friends were designed assuming actions run in the execroot (or a runfiles tree which mirrors the execroot).I think a reasonable approach here would be for us to change build scripts so that they executed in the execroot as their working directory (which means that these injected env vars are valid relative paths), and to recommend that crates explicitly add a
env!("CARGO_MANIFEST_DIR")
prefix to any paths they try to read at build time. We changed where build scripts run recently in #427 so I don't feel too bad about changing it again... This approach seems fairly principled, and gives a very clear workaround for crates which face problems with this.Any required fix pull requests may appear as slightly odd to crate authors (the author may think "the working directory is
env!("CARGO_MANIFEST_DIR")
- why would I need to be explicit?"), but hopefully they'd just find it odd (and understand that alternative build tools may behave differently), rather than objectionable...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it should also work on source files, as we're only referencing "bazel-out" in the build script, which is always generated. But I take your point about this being a bit of a hack, and an approach that doesn't require hunting for execroot would be both more ergonomic and less fragile.
Perhaps one way to solve this would be to add another argument to cargo_build_script() that controls whether the working dir is execroot or the manifest dir? Crates that have bought into the Bazel ecosystem could then consume the locations directly, and third-party crates that assume cargo will set the working dir to the manifest dir for them would continue to function without patching.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That feels like a reasonable compromise to me - we could perhaps also set an additional
BAZEL_EXEC_ROOT
env var in the manifest dir path case, to help folks who are trying to support both well to support conditional behaviour.One challenge I've run into is crates which use
prost-build
, so it may be interesting to run through this as a concrete example:With https://github.com/danburkert/prost/pull/324 (current unreleased, sadly) and this PR, you can set
build_script_env
to something like{"PROTOC": "$(execroot @com_google_protobuf//:protoc)"}
:In exec-root-as-working-directory mode, things should Just Work assuming all other paths (e.g. paths to the protobufs being codegen'd) are using the
$CARGO_MANIFEST_DIR
prefix properly.In cargo-manifest-dir-working-directory mode, it would require the build script to prepend
${BAZEL_EXEC_ROOT}
toPROTOC
, which works but is a bit annoying... Alternatively, we could extend${pwd}
-substitution to the build script runner (which seems pretty reasonable), so that one could simply use:{"PROTOC": "${pwd}/$(execroot @com_google_protobuf//:protoc)"}
(or possibly{"PROTOC": "$${pwd}/$(execroot @com_google_protobuf//:protoc)"}
- I always get lost in the escaping here!)and the build script runner would do the right thing in both modes...
Actually, the more I talk it through, the more I'm convinced we don't need both modes, we just need
${pwd}
-substitution everywhere that we support$(location)
substitution - how does that sound to you?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, solving the prost-build problem was one of the motivations for this PR, as I'm using it in my project too.
Substituting pwd sounds good, I'll look into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think of the latest push? It adds the execroot automatically rather than relying on the user to do so - the rationale being that it's consistent with the way things like genrule() behave. But I can change it to require an explicit ${pwd} reference if you'd prefer.
And if you'd like me to squash these commits to tidy things up, please let me know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I experimented with resolving execpath/${pwd} for rust_binary/rust_test(), but it didn't work - rustc_env is only available at compile time, and if we bake in the execroot, the execution stage is running in a different sandbox, and the path is no longer valid - so they will need to continue using rootpath instead)