Added support for win_flex_bison on Windows

[corco]

As a first step towards compiling on Windows (#307), use WinFlexBison on Windows instead of compiling m4/flex/bison (which doesn't work)

[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 with @googlebot 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.

[google-cla]

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 with @googlebot 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.

[corco]

@googlebot I signed it!

[google-cla]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[mithro]

Is there a way to verify this is working on GitHub Actions?

[hzeller]

Very cool!
I mostly only have one comment (changing the name of the workflow from mac to windows :) ).

Also I suggest if you can and have not already, run the changed bzl and added BUILD file through buildifier (from https://github.com/bazelbuild/buildtools ) which creates a uniform formatting (I don't have any complaints about the formatting on these, but this will make sure it is uniform).

Other than that, we're good to final review and merge once the CI is passing (I suspect it might take a few commits and pushes until github actions are happy)

[hzeller]

Thanks, merged!

[hzeller]

Could this win_flex_configure() be made to return early if we're not on Windows ?

There seems to be an issue with pre-fetching all the needed dependencies vs. what is then actually needed in download later in environments that separate out the fetching and building like on nixos; this is why it needs this patch:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/language-servers/verible/remove-unused-deps.patch

I suspect what is happening: the win_flex_configure() called from the WORKSPACE unconditionally downloads the dependencies , but then on a non-Windows system, the select() in the {bison,flex}.bzl realizes that it doesn't actually needs it, so it then leaves it out of the prepeared download blob.
Later, after disconnect from the network, on build, the unconditional download attempt will fail. At least this is what I think is happening.

Anyway, if here, we could just skip calling the remote_win_flex_bison() and register toolchain part if we're not on windows, that should probably help. Do you think you can add that @corco ?

[corco]

I'll will look at it at the end of the week

[corco]

I took a look. It seems that this issue is part of the problem. There may be a way to fix it in either nix or bazel, but I am not comfortable with either...

I would suggest to either wait until bazel fix the issue, or simply remove downloading win_flex_bison and require the user to install it prior with chocolatey, like the use_local_flex_bison flag. I would move toward that second solution if @hzeller agrees.

[corco]

@hzeller Have you look at my previous comment now that Christmas vacations are over?

[hzeller]

Oh, sorry, indeed I didn't see your previous comment.
I think removing the download and let the user use_local_flex_bison sounds good to me.