Allow dependencies of a genrule to be built for the target platform.

[granaghan]

Description of the feature request:

Per a comment in the source, dependencies of genrules are always built for the host platform. I would like to allow them to be build for the target platform. Specifically, I would like genrules to pass the target platform along in case that information is relevant to any transitive dependencies.

What underlying problem are you trying to solve with this feature?

I need to create an embedded binary with multiple apps. Due to the size cost of relocatable linking, that is not an option for us. As a result, we need to link apps sequentially and update the linker script with a new flash base address after each app is linked.

I tried implementing this as genrule(app1 linker script) <- rust_binary(app1) <- genrule(app1 size info) <- genrule(app2 linker script) <- rust_binary(app2)

I can build app1, app1:size, and app2:linker_script for my target platform (riscv32/none), however building app2 causes app1 to be rebuilt to x86_64/none and causes a link error. Adding target_compatible_with to the genrules to restrict them to riscv32/none results in app1:size to be unable to be build because its target platform is @local_config_platform//:host.

Which operating system are you running Bazel on?

gLinux

What is the output of bazel info release?

release 6.2.1

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

Source comment: https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/genrule/GenRuleBase.java#L271

Any other information, logs, or outputs that you want to share?

No response

[granaghan]

Digging some more, this seems to be an issue related to chaining genrules.
https://bazel.build/reference/be/general#genrule

For genrules, the build system ensures that dependencies are built appropriately: srcs are built (if necessary) for the target configuration, tools are built for the exec configuration, and the output is considered to be for the target configuration.

It is intentional that genrule defines no deps attribute: other built-in rules use language-dependent meta information passed between the rules to automatically determine how to handle dependent rules, but this level of automation is not possible for genrules. Genrules work purely at the file and runfiles level.

Exec-exec compilation: in some cases, the build system needs to run genrules such that the output can also be executed during the build. If for example a genrule builds some custom compiler which is subsequently used by another genrule, the first one has to produce its output for the exec configuration, because that's where the compiler will run in the other genrule. In this case, the build system does the right thing automatically: it builds the srcs and outs of the first genrule for the exec configuration instead of the target configuration. See the user manual for more info.

Can this be made to always follow the srcs vs tools rules or have a flag to disable the exec-exec compilation case?

[fmeum]

This has been traced back to the exec-configured linker_script attribute in rust_binary, see https://bazelbuild.slack.com/archives/CA31HN1T3/p1689202516920939 for details.

Just in case:

You could run bazel cquery 'somepath(A, B)' to print a path between your first and last target, including configs (printed as hashes)
You can then check on which edges the config changes