Hey László, thanks for the message!
IMO the main two points for improvement in windows would be:
1. Simplifying the getting started process / user experience.
2. Providing symlinks by default.
In my experience most Windows users are less proficient with terminal and setting environment variables. Also the instructions on the site are somewhat confusing.
Windows users could benefit a lot from a more automated process. An installer that will fetch dependencies and set the PATH and visual studio environment variables will go a long way.
Or maybe at least set the environment variables / PATH, but update the documentation to more clearly state all the requirements upfront, as right now it's spread over two pages and people glace through that often.
Right now the user experience is a bit messy, something like this:
1. Go to the bazel website, go to Get Bazel
2. Read the requirements:
2.a. Download the Visual C++ Redistributable
2.b Get confused whether you need MSYS2 or not (my understanding is if you want to call bazel run you still need it, and most regular users will probably want to call bazel run). Also note some people I helped skipped that because it didn't look to them as if it's in the requirements section.
3. Go to github and get the right exe.
4. On Windows 10 for some reason quite a few users had an issue downloading and renaming / moving the .exe file. Possibly some Windows defender interference? The Windows File Explorer would freeze and crash often.
5. Set all the PATH variables manually.
5.a. "Wait, do I need python and java?"
6. Ok done.
7. C++ isn't working.
8. Find this other link (Using Bazel on Windows) and find the C++ section
9. Set the PATH
Note that the 2017 BAZEL_VC path on the site was incorrect for a few users I helped with as they were using the community edition:
BAZEL_VC = C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC
10. Get the Windows SDK.
Also note that when updating the bazel.exe for some reason often the file explorer will freeze and crash when deleting/renaming the old one and moving in the new one to replace it (similar to point 4). I'm still not sure what's causing it as I tried to disable Windows Defender and all. I saw it on at least 10 different machines. (Similarly, the Chrome download will be stuck on 100% and just wait for something)
As for symlinks, the --experimental_enable_runfiles is super helpful, but it's always a bit of a gotcha. Any chance to put it as default for Windows? I'm sure it'll save people a lot of headache. Maybe output a warning about it so people can read more, but most will probably want the functionality and parity with other platforms, and not have to use an extra library/manifest to access their files.
Finally, not windows specific, something to handle the Visual Studio Code sourceFileMap path could be nice. Right now users have to set it for every project, and if they have cross project dependencies it becomes even messier. If there was a way to get it to work more nicely with Visual Studio Code that would be great. An alternative would be to figure out a way to get the correct path automatically instead of debugging once, copying the path, etc.
These are the main things really. Otherwise Bazel is finally quite functional on Windows! Perhaps making things like selecting STD version easier would be nice, instead of writing an entire crosstool to do this single thing. A common solution I've seen was to have a .bazelrc with the following:
build --cxxopt="/std:c++latest"
build --cxxopt="--std=c++17"
But building on OSX/Linux will generate a lot of warnings because of the /std:c++latest. If it could forward the --std=c++17 as if it was /std:c++17 for Visual Studio it might be cleaner.
Seems like most teams I met only wanted to set the STD version and either used the .bazelrc or had exactly one person who kinda managed to get through the crosstool tutorials enough to do this exactly one thing (set the std version) and was still quite confused about it. Seems like a lot of work for so little.
Hope this helps!