Windows support

[bspeice]

I realize that Windows isn't always a first-class supported citizen, but it's been harder to set up than I expected.

In WORKSPACE, I've added a compiler with:

rust_repository_set(
    name = "rust_windows_x86_64",
    exec_triple = "x86_64-pc-windows-msvc",
    extra_target_triples = [],
    version = "1.32.0"
)

But when I actually try to compile:

ERROR: C:/users/bspeice/development/empire/core/BUILD:5:1: error executing shell command: 'C:/WINDOWS/system32/bash.exe -c CARGO_MANIFEST_DIR="$(pwd)"/core external/rust_windows_x86_64/bin/rustc.exe "$@" --remap-path-prefix="$(pwd)"=__bazel_redacted_pwd  core/src/lib.rs --crate-name=core...' failed (Exit 1): bash.exe failed: error executing command
  cd C:/users/bspeice/_bazel_bspeice/de34skwq/execroot/__main__
  SET CARGO_PKG_AUTHORS=
    SET CARGO_PKG_DESCRIPTION=
    SET CARGO_PKG_HOMEPAGE=
    SET CARGO_PKG_NAME=corelib
    SET CARGO_PKG_VERSION=0.0.0
    SET CARGO_PKG_VERSION_MAJOR=0
    SET CARGO_PKG_VERSION_MINOR=0
    SET CARGO_PKG_VERSION_PATCH=0
    SET CARGO_PKG_VERSION_PRE=
  C:/WINDOWS/system32/bash.exe -c CARGO_MANIFEST_DIR=$(pwd)/core external/rust_windows_x86_64/bin/rustc.exe "$@" --remap-path-prefix="$(pwd)"=__bazel_redacted_pwd  core/src/lib.rs --crate-name=corelib --crate-type=rlib --codegen=metadata=--1467924155 --out-dir=bazel-out/x64_windows-fastbuild/bin/core --codegen=extra-filename=--1467924155 --codegen=opt-level=0 --codegen=debuginfo=0 --emit=dep-info,link --color=always --target=x86_64-pc-windows-msvc --codegen=linker=C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools/VC/Tools/MSVC/14.16.27023/bin/HostX64/x64/link.exe --codegen link-args=/nologo /SUBSYSTEM:CONSOLE /MACHINE:X64 /DEFAULTLIB:msvcrt.lib /DEBUG:FASTLINK /INCREMENTAL:NO
Execution platform: @bazel_tools//platforms:host_platform
error: couldn't read : The system cannot find the path specified. (os error 3)

If it's helpful, there were some earlier issues with symlinks:

cannot create symbolic link bazel-out -> C:/users/bspeice/_bazel_bspeice/de34skwq/execroot/__main__/bazel-out:  Cannot create junction (name=C:\users\bspeice\development\empire\bazel-out, target=C:\users\bspeice\_bazel_bspeice\de34skwq\execroot\__main__\bazel-out): junction already exists with different target
  cannot create symbolic link bazel-empire -> C:/users/bspeice/_bazel_bspeice/de34skwq/execroot/__main__:  Cannot create junction (name=C:\users\bspeice\development\empire\bazel-empire, target=C:\users\bspeice\_bazel_bspeice\de34skwq\execroot\__main__): junction already exists with different target

I've tried with both the MSVC and GNU toolchains, no luck. I think at least the ld path needs quotations, but even when that's added, I still get the same failures. Is there something else that can be done to figure out how best to support Windows?

EDIT: What's going on is that the args expansion that's supposed to happen via "$@" isn't expanding; is this an issue with Bazel itself, that the run_shell action isn't expanding "$@" correctly?

[bspeice]

Bazel mainline is already aware of this issue, so I think Rust will "Just Work" once it gets cleaned up there: bazelbuild/bazel#7122

[mfarrugi]

Thanks for figuring out that this is an upstream issue at the moment. When it's fixed, I would be surprised if everything just works. In general the rules are written using the action apis, but there are places where system dependencies and unix assumptions leak in.. and then there is also some ignorance around where windows behavior is different (at least on my part).

…

On Sun, Feb 24, 2019, 13:04 bspeice ***@***.***> wrote: Closed #197 <#197>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#197 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACLjeEaaYCUM2YHUsuVZ4hWcRWK2Sm4eks5vQtQjgaJpZM4bOXU2> .

[bspeice]

Fair; but changing the quoting behavior isn't hard relative to fixing how process are constructed upstream. Will take a look again once the next version of bazel is released.

[damienmg]

I second @mfarrugi, I don't think this will work out of the box. At least I know protobuf support won't (I might even added specific comments about windows support).