cargo_build_script fails on Windows with bazel defaults

[dae]

Attempting to build a crate with cargo-raze's gen_buildrs = true fails on Windows:

thread 'main' panicked at 'Unable to start binary: Os { code: 267, kind: Other,
message: "The directory name is invalid." }', external/io_bazel_rules_rust/cargo
/cargo_build_script_runner/lib.rs:104:60

It appears to be happening on this line, as the path it points to does not exist:

rules_rust/cargo/cargo_build_script_runner/bin.rs

Line 48 in 169476f

.current_dir(manifest_dir.clone())

I am guessing this is because I have not enabled developer mode/runfiles: https://docs.bazel.build/versions/master/windows.html#enable-symlink-support

While I could do so on my local development machine, I fear this would not be possible when running CI with GitHub actions/Travis/etc. Have I missed something?

[dae]

As a follow-up to this, I ran into further issues when trying with --enable_runfiles. When attempting to compile a crate like libsqlite3-sys, the C compiler failed to find includes like stdarg.h. Bazel seems to be able to compile C++ files directly, so my guess is this is an issue with cargo_build_script not passing the relevant envvars into the build script.

[dae]

The following seems to help things move along:

diff --git a/cargo/cargo_build_script.bzl b/cargo/cargo_build_script.bzl
index 3e2a8cc..b18ede4 100644
--- a/cargo/cargo_build_script.bzl
+++ b/cargo/cargo_build_script.bzl
@@ -1,4 +1,4 @@
-load("@io_bazel_rules_rust//rust:private/rustc.bzl", "BuildInfo", "DepInfo", "get_cc_toolchain", "get_compilation_mode_opts", "get_linker_and_args")
+load("@io_bazel_rules_rust//rust:private/rustc.bzl", "BuildInfo", "DepInfo", "get_cc_compile_env", "get_cc_toolchain", "get_compilation_mode_opts", "get_linker_and_args")
 load("@io_bazel_rules_rust//rust:private/utils.bzl", "find_toolchain")
 load("@io_bazel_rules_rust//rust:rust.bzl", "rust_binary")
 load("@bazel_tools//tools/cpp:toolchain_utils.bzl", "find_cpp_toolchain")
@@ -52,6 +52,8 @@ def _cargo_build_script_run(ctx, script):
     # Pull in env vars which may be required for the cc_toolchain to work (e.g. on OSX, the SDK version).
     # We hope that the linker env is sufficient for the whole cc_toolchain.
     cc_toolchain, feature_configuration = get_cc_toolchain(ctx)
+    cc_env = get_cc_compile_env(cc_toolchain, feature_configuration)
+    env.update(**cc_env)
     _, _, linker_env = get_linker_and_args(ctx, cc_toolchain, feature_configuration, None)
     env.update(**linker_env)
 
diff --git a/rust/private/rustc.bzl b/rust/private/rustc.bzl
index fe21f0c..aa4dbfc 100644
--- a/rust/private/rustc.bzl
+++ b/rust/private/rustc.bzl
@@ -17,6 +17,7 @@ load("@io_bazel_rules_rust//rust:private/legacy_cc_starlark_api_shim.bzl", "get_
 load(
     "@bazel_tools//tools/build_defs/cc:action_names.bzl",
     "CPP_LINK_EXECUTABLE_ACTION_NAME",
+    "C_COMPILE_ACTION_NAME",
 )
 load(
     "@bazel_tools//tools/cpp:toolchain_utils.bzl",
@@ -207,6 +208,17 @@ def get_cc_toolchain(ctx):
     )
     return cc_toolchain, feature_configuration
 
+def get_cc_compile_env(cc_toolchain, feature_configuration):
+    compile_variables = cc_common.create_compile_variables(
+        feature_configuration = feature_configuration,
+        cc_toolchain = cc_toolchain,
+    )
+    return cc_common.get_environment_variables(
+        feature_configuration = feature_configuration,
+        action_name = C_COMPILE_ACTION_NAME,
+        variables = compile_variables,
+    )
+
 def get_cc_user_link_flags(ctx):
     if (len(BAZEL_VERSION) == 0 or
         versions.is_at_least("0.18.0", BAZEL_VERSION)):

But then I run into further problems - blake3's build script seems to run indefinitely, and for some reason the build script in my local crate can't find the crates it requires. They're passed in as deps and are available on other platforms, so it seems to be another Windows-specific issue.

[dae]

I've sent through some PRs for some of the above mentioned issues. I imagine the original issue of runfiles being required for crate build scripts is not an easy one to solve, and I figure I'm just going to have to keep my crate buildable with cargo for testing on Windows in CI.