-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Windows Support #22544
Comments
I don’t think we have a good estimate of how difficult it would be to build on Windows; it’s been a while since we last discussed it internally. We don’t seem to get much interest from robotics or robotics-adjacent researchers on Windows, so we haven’t prioritized it at all. (People who are interested, feel free to upvote this issue.) Relatedly, we also have #14967 open, requesting Drake to be more portable (and/or ship more flavors of packages). Like that issue, I’ll keep this issue open to serve as a discussion point – in this case about Windows instead of other Linux distributions. Relatedly, we have also been working on #20731 to consolidate Drake’s dependencies and reduce our reliance on OS-installed dependencies, which should also help with portability. Also note that our CMake build system is just a thin veneer over Bazel, so CMake isn’t very relevant to how portable Drake is. Bazel does support Windows in general, so the question here revolves around the fine-grained details of individual files, more than the kinds of tools we’re using. In any case, I can’t imagine that we would ever support creating Windows DLLs; those are a nightmare to maintain in a project as large as ours, with millions of lines of code across a dozen heterogenous programming languages. Instead, the avenue that might work would be to create static LIB libraries – see #16882 for a related request on that front. For users interested in Windows, one thing y'all could do to help move it forward would be to try building on Windows, see what kinds of problems exist, and help inventory them here. If there are easy bugs to fix right away and the fix is not disruptive, we would be happy to accept pull requests with those enhancements. (It might be worth waiting another ~month or so before people try that, to allow #20731 to make a bit more progress -- starting by turning off most dependencies using our flags will probably make the initial testing easier).
FWIW – medium term, another way to deploy a Linux-based Drake running on Windows might be by running a Drake-based Linux binary under WSL2, using an RPC protocol to communicate back into the Windows application. In the meantime, you could also just try playing around with Drake in a VM to see how well it fits your use case in the first place. Ultimately, Drake is also open source, so users should feel free to fork it and adapt it for their own needs. People who only need small bits of Drake might be able to just copy some of our source files into their own project, instead of using our build system. |
Thanks for the reply. Static libs are all we'd want in any case. I'll have to speak with my team leads and see how they feel about the potential of taking on a windows port ourselves (when they get back from vacation). |
Sorry if this has been brought up before. I couldn't find any closed issues that repeated this ask. But given the use of cmake as a build system how difficult would it be to add windows support? I am looking to experiment with drake for a work project and we all use windows as an operating system in the office. I could maybe setup a VM to run ubuntu but ultimately we'd want to be consuming the libs in a windows C++ environment. So the output would need to be libs compiled for windows.
The text was updated successfully, but these errors were encountered: