-
Notifications
You must be signed in to change notification settings - Fork 522
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat(builtin): support $(rootpath), $(execpath), predefined & custom …
…variables in templated_args * patch runfiles.bash helper to support $(rootpath) * add support for $(rootpath), $(execpath), predefined & custom variables to expand_location_into_runfiles helper function This applies to `templated_args` in nodejs_binary, nodejs_test & jasmine_node_test and to `args` in params_file Also fixes ambiguity of `$(rlocation $(location ...))` expansion as it is not clear that `$(rlocation ...)` is not meant to be expanded but rather passed down to the shell script for execution. This is now more clear with `$$(rlocation $(manifestpath ...))` which follows the Bazel "Make" variable expansion convention. For example, `templated_args = ["--node_options=--require=$$(rlocation $(manifestpath :jasmine_shared_env_bootstrap.js))",],`. `templated_args` in nodejs_binary, nodejs_test & jasmine_node_test is now… Subject to 'Make variable' substitution. See https://docs.bazel.build/versions/master/be/make-variables.html. 1. Predefined source/output path substitions is applied first: Expands all `$(execpath ...)`, `$(rootpath ...)` and legacy `$(location ...)` templates in the given string by replacing with the expanded path. Expansion only works for labels that point to direct dependencies of this rule or that are explicitly listed in the optional argument targets. See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_label_variables. Use `$(rootpath)` and `$(rootpaths)` to expand labels to the runfiles path that a built binary can use to find its dependencies. This path is of the format: - `./file` - `path/to/file` - `../external_repo/path/to/file` Use `$(execpath)` and `$(execpaths)` to expand labels to the execroot (where Bazel runs build actions). This is of the format: - `./file` - `path/to/file` - `external/external_repo/path/to/file` - `<bin_dir>/path/to/file` - `<bin_dir>/external/external_repo/path/to/file` The legacy `$(location)` and `$(locations)` expansion is DEPRECATED as it returns the runfiles manifest path of the format `repo/path/to/file` which behaves differently than the built-in `$(location)` expansion in args of *_binary and *_test rules which returns the rootpath. See https://docs.bazel.build/versions/master/be/common-definitions.html#common-attributes-binaries. The legacy `$(location)` and `$(locations)` expansion also differs from how the builtin `ctx.expand_location()` expansions of `$(location)` and `$(locations)` behave as that function returns either the execpath or rootpath depending on the context. See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_label_variables. The behavior of `$(location)` and `$(locations)` expansion may change in the future with support either being removed entirely or the expansion changed to return the same path as `ctx.expand_location()` returns for these. The recommended approach is to now use `$(rootpath)` where you previously used $(location). To get from a `$(rootpath)` to the absolute path that `$$(rlocation $(location))` returned you can either use `$$(rlocation $(rootpath))` if you are in the `templated_args` of a `nodejs_binary` or `nodejs_test`: BUILD.bazel: ``` nodejs_test( name = "my_test", data = [":bootstrap.js"], templated_args = ["--node_options=--require=$$(rlocation $(rootpath :bootstrap.js))"], ) ``` or if you're in the context of a .js script you can pass the $(rootpath) as an argument to the script and use the javascript runfiles helper to resolve to the absolute path: BUILD.bazel: ``` nodejs_test( name = "my_test", data = [":some_file"], entry_point = ":my_test.js", templated_args = ["$(rootpath :some_file)"], ) ``` my_test.js ``` const runfiles = require(process.env['BAZEL_NODE_RUNFILES_HELPER']); const args = process.argv.slice(2); const some_file = runfiles.resolveWorkspaceRelative(args[0]); ``` NB: Bazel will error if it sees the single dollar sign $(rlocation path) in `templated_args` as it will try to example `$(rlocation)` since we now expand predefined & custom "make" variables such as `$(COMPILATION_MODE)`, `$(BINDIR)` & `$(TARGET_CPU)` using `ctx.expand_make_variables`. See https://docs.bazel.build/versions/master/be/make-variables.html. To prevent expansion of `$(rlocation)` write it as `$$(rlocation)`. Bazel understands `$$` to be the string literal `$` and the expansion results in `$(rlocation)` being passed as an arg instead of being expanded. `$(rlocation)` is then evaluated by the bash node launcher script and it calls the `rlocation` function in the runfiles.bash helper. For example, the templated arg `$$(rlocation $(rootpath //:some_file))` is expanded by Bazel to `$(rlocation ./some_file)` which is then converted in bash to the absolute path of `//:some_file` in runfiles by the runfiles.bash helper before being passed as an argument to the program 2. Predefined variables & Custom variables are expanded second: Predefined "Make" variables such as $(COMPILATION_MODE) and $(TARGET_CPU) are expanded. See https://docs.bazel.build/versions/master/be/make-variables.html#predefined_variables. Custom variables are also expanded including variables set through the Bazel CLI with --define=SOME_VAR=SOME_VALUE. See https://docs.bazel.build/versions/master/be/make-variables.html#custom_variables. Predefined genrule variables are not supported in this context.
- Loading branch information
1 parent
8fd0bc2
commit 5358d56
Showing
21 changed files
with
384 additions
and
124 deletions.
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
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,43 @@ | ||
"Unit tests for //internal/common:expand_into_runfiles.bzl" | ||
|
||
load("@bazel_skylib//lib:unittest.bzl", "asserts", "unittest") | ||
load("//internal/common:expand_into_runfiles.bzl", "expand_location_into_runfiles") | ||
|
||
def _impl(ctx): | ||
env = unittest.begin(ctx) | ||
|
||
conversions = { | ||
"$(location //:package.json)": "build_bazel_rules_nodejs/package.json", | ||
"$(location :a)": "build_bazel_rules_nodejs/internal/common/test/foo/bar/a.txt", | ||
"$(location params_file.spec.js)": "build_bazel_rules_nodejs/internal/common/test/params_file.spec.js", | ||
"$(locations :locations_in)": "build_bazel_rules_nodejs/package.json build_bazel_rules_nodejs/internal/common/test/foo/bar/a.txt build_bazel_rules_nodejs/internal/common/test/params_file.spec.js", | ||
"$(rootpath //:package.json)": "./package.json", | ||
"$(rootpath :a)": "internal/common/test/foo/bar/a.txt", | ||
"$(rootpath params_file.spec.js)": "internal/common/test/params_file.spec.js", | ||
"$(rootpaths :locations_in)": "./package.json internal/common/test/foo/bar/a.txt internal/common/test/params_file.spec.js", | ||
} | ||
|
||
for key in conversions: | ||
asserts.equals(env, "%s" % conversions[key], expand_location_into_runfiles(ctx, "%s" % key)) | ||
asserts.equals(env, " %s " % conversions[key], expand_location_into_runfiles(ctx, " %s " % key)) | ||
asserts.equals(env, "%s%s" % (conversions[key], conversions[key]), expand_location_into_runfiles(ctx, "%s%s" % (key, key))) | ||
asserts.equals(env, "%s %s" % (conversions[key], conversions[key]), expand_location_into_runfiles(ctx, "%s %s" % (key, key))) | ||
asserts.equals(env, " %s %s " % (conversions[key], conversions[key]), expand_location_into_runfiles(ctx, " %s %s " % (key, key))) | ||
asserts.equals(env, "a%sb%sc" % (conversions[key], conversions[key]), expand_location_into_runfiles(ctx, "a%sb%sc" % (key, key))) | ||
|
||
return unittest.end(env) | ||
|
||
expand_into_runfiles_test = unittest.make( | ||
impl = _impl, | ||
attrs = { | ||
"deps": attr.label_list(default = [ | ||
"//:package.json", | ||
"params_file.spec.js", | ||
":a", | ||
":locations_in", | ||
], allow_files = True), | ||
}, | ||
) | ||
|
||
def expand_into_runfiles_test_suite(): | ||
unittest.suite("expand_into_runfiles_tests", expand_into_runfiles_test) |
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.