New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building on Windows #276
Comments
No reason, wasn't tested. As we stated in our FAQ we are not working on Windows support because we don't have manpower for that at the moment. The support of windows is highly experimental. |
Created pull request #277 to clarify situation for others, too. |
FYI one of the major blockers for proper Windows support (that is, without the need to run with elevated permissions) is that Bazel uses symlinks extensively, and while NTFS supports symlinks, creating symlinks requires that the user has This is even further complicated by According to Microsoft, the reason why this restriction exists is that: I was not able to find any more details or examples of said possible vulnerabilities aside from symlink races when creating symlinks under world-writable directories such as Unfortunately, from what I can observe, while symlink support on Windows exists, using the current implementation for most common use cases is pretty much impractical due to this restriction: https://www.google.com/search?q=SeCreateSymbolicLinkPrivilege |
We could do with copying instead of symlinking and that would probably already be a good improvement over standard file system. There's a also the possibility of creating a kernel module to support our own kind of symlink or use the ntfs symlinking with a special service. Anyway doing a FS abstraction that use copy instead of symlink should work well for a first step. |
SGTM. While copying instead of symlinking will incur a significant performance hit due to the I/O overhead, it would be a good first step. There is also the issue of Skylark rules that directly invoke |
I think file operation abstraction should be provied at the skylark level On Mon, Jul 6, 2015 at 1:02 PM David Z. Chen notifications@github.com
|
FWIW, I think we could replace symlinks with hardlinks (files) and junctions (directories). |
Just +1 to this issue: I believe that supporting many build platforms is critical to the wide adoption of a build tool like Bazel. |
By the way, we have set-up a goal to have basic windows support by the end of the year so stay tuned! |
See the roadmap: http://bazel.io/roadmap.html. |
A gentle ping on this issue. There is strong interest from TensorFlow users to build and use TensorFlow natively on Windows (tensorflow/tensorflow#17). Perhaps let's give an update on the status of Bazel on Windows? |
Dmitry has some changes (https://github.com/dslomov/bazel-windows) that allow Bazel to bootstrap. However, he's only working on it part-time; we're planning to make a more concerted push here early next year. |
@davidzchen While creating symbolic links on Windows requires special permissions, it is possible to create hard links and directory junctions (basically symbolic links to directories) as a standard user. See https://msdn.microsoft.com/en-us/library/windows/desktop/aa365006(v=vs.85).aspx for details. The "mklink" command (in cmd.exe not PowerShell) can be used to quickly test hard links and junctions. |
I don't see symlinks on windows being as big an issue as it is being made out to be. The first step should obviously be to get things building on windows with elevated perms. I'm sure pretty much everyone interested in windows support could live with that inconvenience for the short term. |
Indeed, symlinks is largely solved now using hard links and junctions. But there's still more to do. |
+1 for WIndows support (TensorFlow) |
+1 |
+1 |
We have started to upstream Dmitry's changes, as well as done some experiments to check if our approach to symlink handling on Windows is going to work. Experiments look promising and we hope to have bootstrap working for master in the next couple of weeks. |
nice |
Needed for #276. -- MOS_MIGRATED_REVID=113766886
This is the only variable we need to propagate to bootstrap Bazel. We might need to have a more principled approach for this, e.g. for MakeVariables. Needed for #276. -- MOS_MIGRATED_REVID=113777759
Native protoc-windows.exe fails to support paths longer that 1024 characters. Needed for #276. RELNOTES: None.
Native protoc-windows.exe fails to support paths longer that 1024 characters. Needed for #276. -- MOS_MIGRATED_REVID=113834005
…xe" . A small step towards the resolution of #276. -- MOS_MIGRATED_REVID=114330517
Needed for #276. -- MOS_MIGRATED_REVID=114527619
Needed for #276. -- MOS_MIGRATED_REVID=114529775
Needed for #276. -- MOS_MIGRATED_REVID=114693711
…mentation. Progress on #276. -- MOS_MIGRATED_REVID=114740700
Progress towards #276. -- MOS_MIGRATED_REVID=114829911
Needed for #276. -- MOS_MIGRATED_REVID=114838538
cygwin lies about it, stripping the '.exe' suffix. Needed for #276. -- MOS_MIGRATED_REVID=114860126
… on mingw. Needed for #276. -- MOS_MIGRATED_REVID=114867808
Quotation mark character is significant for Win32's CreateProcess. It should always be properly escaped when occuring inside arguments. We might devise a common solution in GenRule for that, but for now this change fixes the only genrule we use that runs into this issue. Needed for #276. -- MOS_MIGRATED_REVID=114881441
…be found. On Windows, ijar.exe needs msys-2.0.dll and zlib1.dll in PATH. Needed for #276. -- MOS_MIGRATED_REVID=114947735
Now that we can almost bootstrap on Windows, I filed a bunch of bugs to track the work that remains to be done in order to call our Windows support usable: |
Thanks Lukacs ! Let's close this one when we can bootstrap on Windows and CI is up and running! |
Win32 have no good API for that (basically we need to resort to ioctl call). Shelling out to mklink. Needed for #276. -- MOS_MIGRATED_REVID=115040968
The building docs mention to run MSYS2 shell, excluding mingw32 and mingw64. Sadly there is no reason or bug for using anything other than MSYS2. Could anyone please elaborate, why the others do not work?
The text was updated successfully, but these errors were encountered: