Avoid double building cargo_build_script.data targets

[UebelAndre]

Before this change targets passed to cargo_build_script.data would get built multiple times (once per configuration)

% bazel cquery 'filter(//test/cargo_build_script/location_expansion:target_data.txt, deps(//test/cargo_build_script/location_expansion:build_rs))'
//test/cargo_build_script/location_expansion:target_data.txt (be33641)
//test/cargo_build_script/location_expansion:target_data.txt (a1c326f)

We can see that this is the exec (a1c326f) and target (be33641) configurations.

% bazel config a1c326f be33641
INFO: Displaying diff between configs a1c326f and be33641
Displaying diff between configs a1c326f and be33641
FragmentOptions com.google.devtools.build.lib.analysis.PlatformOptions {
  platforms: [@@internal_platforms_do_not_use//host:host], [@@bazel_tools//tools:host_platform]
}
FragmentOptions com.google.devtools.build.lib.analysis.config.CoreOptions {
  compilation_mode: opt, fastbuild
  is exec configuration: true, false
  platform_suffix: exec, null
}
FragmentOptions com.google.devtools.build.lib.rules.android.AndroidConfiguration$Options {
  fat_apk_cpu: [], [armeabi-v7a]
}
FragmentOptions com.google.devtools.build.lib.rules.cpp.CppOptions {
  copt: [-g0], []
  cxxopt: [-g0], []
  strip: always, sometimes
}
FragmentOptions com.google.devtools.build.lib.rules.java.JavaOptions {
  java_runtime_version: remotejdk_11, local_jdk
  jvmopt: [-XX:ErrorFile=/dev/stderr], []
}

This is caused by data being passed to the underlying rust binary in cargo_build_script_wrapper.bzl.

The fix for this ends up requiring some gymnastics as many existing uses of cargo_build_script rely on data files being available within the runfiles of cargo_build_script.script. This change accounts for that by creating a wrapper rule for the build script that symlinks the cfg=exec Rust binary (which is the actual Cargo build script) and updating the cargo_build_script rule to consume it as cfg=target. Within the cargo_build_script rule this means the script target and it's data attribute files will be in cfg=target but the binary itself will have been built for cfg=exec and will be runnable on the exec platform.

We see after this change that data targets only appear once now

% bazel cquery 'filter(//test/cargo_build_script/location_expansion:target_data.txt, deps(//test/cargo_build_script/location_expansion:build_rs))'
//test/cargo_build_script/location_expansion:target_data.txt (be33641)

[UebelAndre]

@scentini This change fails the compatible_with tests and I don't understand why (or really how compatible_with works), can you help me understand what's happening? 😅

% bazel test //test/cargo_build_script/... --keep_going
ERROR: /Users/rules_rust/test/cargo_build_script/compatible_with/BUILD.bazel:27:19: in cargo_build_script rule //test/cargo_build_script/compatible_with:empty_build_script: dependency //test/cargo_build_script/compatible_with:empty_build_script- doesn't support expected environment: //test/cargo_build_script/compatible_with:bar
ERROR: /Users/rules_rust/test/cargo_build_script/compatible_with/BUILD.bazel:27:19: Analysis of target '//test/cargo_build_script/compatible_with:empty_build_script' failed
WARNING: errors encountered while analyzing target '//test/cargo_build_script/compatible_with:empty_build_script', it will not be built.
INFO: Analyzed 18 targets (6 packages loaded, 47 targets configured).
WARNING: errors encountered while analyzing target '//test/cargo_build_script/compatible_with:test_compatible_with', it will not be built.
Analysis failed

[UebelAndre]

@scentini This change fails the compatible_with tests and I don't understand why (or really how compatible_with works), can you help me understand what's happening? 😅

% bazel test //test/cargo_build_script/... --keep_going
ERROR: /Users/rules_rust/test/cargo_build_script/compatible_with/BUILD.bazel:27:19: in cargo_build_script rule //test/cargo_build_script/compatible_with:empty_build_script: dependency //test/cargo_build_script/compatible_with:empty_build_script- doesn't support expected environment: //test/cargo_build_script/compatible_with:bar
ERROR: /Users/rules_rust/test/cargo_build_script/compatible_with/BUILD.bazel:27:19: Analysis of target '//test/cargo_build_script/compatible_with:empty_build_script' failed
WARNING: errors encountered while analyzing target '//test/cargo_build_script/compatible_with:empty_build_script', it will not be built.
INFO: Analyzed 18 targets (6 packages loaded, 47 targets configured).
WARNING: errors encountered while analyzing target '//test/cargo_build_script/compatible_with:test_compatible_with', it will not be built.
Analysis failed

I believe I've fixed it.

[illicitonion]

This is really cute, thanks for putting it together!

Are you imagining putting together any affordances for using this from crate_universe, or leaving folks to do that on their own?

[UebelAndre]

This is really cute, thanks for putting it together!

Are you imagining putting together any affordances for using this from crate_universe, or leaving folks to do that on their own?

What do you mean? This change shouldn't require any interface changes so any direct uses of cargo_build_script (wrapper/top level symbol) should start using this.

[illicitonion]

This is really cute, thanks for putting it together!
Are you imagining putting together any affordances for using this from crate_universe, or leaving folks to do that on their own?

What do you mean? This change shouldn't require any interface changes so any direct uses of cargo_build_script (wrapper/top level symbol) should start using this.

I mean right now there are annotations like build_script_data which generate attributes on a cargo_build_script target which is auto-generated for the crates - do we want to change what gets generated in the BUILD files?