Windows support

[majcherm-da]

This resolves 2 issues I raised for running rules_scala on Windows, that is:

• 'No such file or directory' on Windows #641 (%1 is not a valid Win32 application)
• 'Unused dependency checking' is causing failures in rules_scala/test build #642 (valid dependencies reported as usused on Windows)

Main change is a port of Bazel's exe launcher from java rules to scala rules. Without it Bazel attempts to execute a bash script (generated from java_stub_template) as Bazel's executable, which fails on Windows.

See https://github.com/bazelbuild/bazel/blob/8ac46c157c5da63e97a5825316ce6f0c3290e189/src/main/java/com/google/devtools/build/lib/bazel/rules/java/BazelJavaSemantics.java#L411 for how it's done in java rules.

The UnusedDependencyChecker is fixed by normalizing Windows paths, replacing backslashes with slashes. Without it all targets report unused deps on Windows.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[majcherm-da]

I signed it!

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[ittaiz]

@majcherm-da Thank you and sorry for the long silence. I'll get to this very soon.
I've skimmed and just want to verify something- the "exe" launcher which is a java_binary is used only in windows, right?
Also this starts a jvm which then starts a windows executable from core-bazel?
Is this indirection mandatory? Sounds like it's added complexity and performance but I don't know the windows challenges well enough.

[ittaiz]

Also,
@johnynek I think this relates to the discussion we had about dropping scala_binary and its friends in favor of java_binary and friends.
We are making some headway at Wix towards being able to move from scala_junit_test to using java_test (still not there but I think we're close).
If we can run scala_test on java_test/java_binary then we can remove a lot of code/concerns from this repo.

[johnynek]

Thanks for the PR.

Is there any way we can get CI testing Windows so we don’t break this going forward?

If this is too much pain for the PR I’m in favor of a merge and then follow up later, but I guess we’ll break it soon without CI.

[majcherm-da]

@ittaiz Yes, the "exe" java_binary is used only on Windows. It's java based, since it was the simpliest way I found to create the resulting exe file based on the Bazel's bazel_tools/tools/launcher/launcher.exe (porting the solution from Bazel's JavaBinary). The launcher.exe (binary file) needs to be appended with target specific arguments, which together constitues a final exe file. Bazel's JavaBinary is written in Java itself, but here the entrypoint is a Skylark rule that's why it feels a bit unnatrual. The "exe" java_binary is only used to create the final exe file, which is a replacement for the sh start script for Linux/Mac to start the target app/binary, so the statement that "this starts a jvm which then starts a windows executable from core-bazel" is not fully correct. As an alternative, to get rid of the need of starting JVM to create the exe file, we could re-implement the Bazel's LaunchInfo and a merge of it's output with the laucher.exe binary with sth. more lightweight, like a run_shell call, but, not mentioning the rewrite itself, it might be a bit tricky to do in bash as it would need to support the runfiles.rlocation to obtain the path of the launcher.exe.

[johnynek]

can we close this since #718 includes everything here?