Skip to content
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

Add tool executables (from FilesToRunProvider) to action inputs. #10110

Closed
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -197,7 +197,6 @@ private CommandHelper(
Artifact executableArtifact = tool.getExecutable();
// If the label has an executable artifact add that to the multimaps.
if (executableArtifact != null) {
resolvedToolsBuilder.add(executableArtifact);
mapGet(tempLabelMap, label).add(executableArtifact);
// Also send the runfiles when running remotely.
toolsRunfilesBuilder.add(tool.getRunfilesSupplier());
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -44,6 +44,9 @@ public FilesToRunProvider(
NestedSet<Artifact> filesToRun,
@Nullable RunfilesSupport runfilesSupport,
@Nullable Artifact executable) {
if (executable != null) {
filesToRun = NestedSetBuilder.fromNestedSet(filesToRun).add(executable).build();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will create an extra NestedSet instance for every call site, most importantly, in the constructor of FileConfiguredTarget, which means an extra object for each input file, which is probably unacceptable overhead.

How about special-casing at least #fromSingleExecutableArtifact() so that this overhead is not present?

Given that the only other call site is in RuleConfiguredTargetBuilder#build(), I'd prefer putting logic there because, well, that place already has logic. In addition to being a personal preference, you also have more information, notably, ruleContext.getRule().getRuleClassObject().isSkylark(), which you can use to determine whether this is a Starlark rule and thus adding the binary to the nested set is necessary.

Even better is changing SkylarkRuleConfiguredTargetUtil#addSimpleProviders() -- that place has control over both the executable and filesToBuildfields ofRuleConfiguredTargetBuilderand is specific to Starlark rules, so you can just add the "executable is forcibly added tofilesToRun`" logic there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that the only other call site is in RuleConfiguredTargetBuilder#build(), I'd prefer putting logic there because, well, that place already has logic.

Done.

}
this.filesToRun = filesToRun;
this.runfilesSupport = runfilesSupport;
this.executable = executable;
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -799,10 +799,6 @@ public Builder addTool(Artifact tool) {
* source code).
*/
public Builder addTool(FilesToRunProvider tool) {
Artifact executable = tool.getExecutable();
if (executable != null) {
addTool(executable);
}
addTransitiveTools(tool.getFilesToRun());
addRunfilesSupplier(tool.getRunfilesSupplier());
return this;
Expand Down