Windows Support #71
Windows Support #71
Conversation
|
On the CI side, I think github actions probably makes sense, and we should probably switch the Linux builds over from Travis while we're at it. |
yodaldevoid
force-pushed
the
windows
branch
15 times, most recently
from
f21e944
to
2998932
Compare
|
Shoutout to @nelsonjchen for his previous work on this. It helped a lot when minimizing the dockerfiles. I've minimized everything as far as possible without breaking something. I've added in this PR dockerfiles for the MSVC and GNU toolchains. Also, I've moved all of the CI builds over to GitHub Actions. It is crazy how easy it is to reuse the entire testing framework is between all of the versions built. |
|
|
||
| FROM mcr.microsoft.com/windows/servercore:1809 | ||
|
|
||
| SHELL ["powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"] |
There was a problem hiding this comment.
It looks like golang's image doesn't set -NoLogo or -ExecutionPolicy Bypass: https://github.com/docker-library/golang/blob/master/1.15/windows/windowsservercore-1809/Dockerfile#L10. Do you know why there's a difference there?
There was a problem hiding this comment.
I set -NoLogo because I don't see a reason to have the PowerShell version information and copyright info printed at the start of each command as it's just noise.
As for the -ExecutionPolicy Bypass, I think that might be a leftover from another Windows docker tutorial I had followed. I don't see a reason it needs to be kept.
| @@ -0,0 +1,72 @@ | |||
| # escape=` | |||
|
|
|||
| # IMAGES BUILT FROM THIS DOCKERFILE ARE NOT TO BE SHARED ON PUBLIC DOCKER HUBs. | |||
There was a problem hiding this comment.
The intent of this PR is to produce images that are to be shared on public Docker hubs, right?
There was a problem hiding this comment.
I'm not entirely sure at this point. I had completely missed this license issue until I was reading through @nelsonjchen's implementation. This issue was brought up by them before a few years ago and I didn't see any discussion about it.
I see value in providing a dockerfile for a base Rust on Windows image, but I don't know whether this repo is the right place for that. If we do keep this base dockerfile here, we would just need to make sure not to add it to the manifest file.
yodaldevoid
force-pushed
the
windows
branch
2 times, most recently
from
a590ae1
to
abe18c3
Compare
|
Could you put " |
This dockerfile cannot be pushed to public hubs due to licensing restrictions, but we might as well provide the dockerfile for others and test against it. Please see the comment at the top of the MSVC template file for more information. Co-authored-by: Nelson Chen <[email protected]>
Co-authored-by: Nelson Chen <[email protected]>
|
How can we bring this forward? |
|
@lippertmarkus I think the one open question is if we want to have the MSVC toolchain dockerfile/template in this repo despite the fact that it can currently never be uploaded to Docker Hub. I could split this PR up so that all changes but the MSVC toolchain can be merged now. |
|
IMHO it should be enough to state at the Docker Hub page that by using the image one agrees to the terms of the MSVC toolchain. Can you just open an issue at https://github.com/microsoft/Windows-Containers/issues asking whether it's fine to include the toolchain to provide an official Rust image for Windows? I mean this also helps them to further emerge Windows Containers |
|
@lippertmarkus I will ask, but going off of paragraph four of this official blog post (which is called out in the big wall of text in the MSVC Dockerfile), any Dockerfiles with the MSVC build tools are only meant for personal use or use within a organization. They even explicitly note that you should not upload containers containing the MSVC build tools to a public Docker hub. |
|
Thanks for sharing. That's interesting as Microsoft is using the Build Tools in their official dotnet framework docker images (https://github.com/microsoft/dotnet-framework-docker/blob/3b2ac5bcda7603b94c0b6399355f3d0c0c1eb512/src/sdk/4.8/windowsservercore-1909/Dockerfile#L21-L30) and that would mean you wouldn't be allowed to use those official images without having a Visual Studio License 😄 Let's see what they're saying. |
|
I created microsoft/Windows-Containers#102 |
Thank you for that. My free time suddenly disappeared last week and this feel by the wayside. |
|
Hey, sorry for dropping this for a while! The main concern is around the licensing of the VS components as you've been discussing upthread. It seems a bit unfortunate to only publish a GNU-based image as MSVC has been the recommended Windows target for quite a while. If we just can't publish an MSVC image then I guess that's the best we can do, but hopefully the licensing situation is a bit less drastic than that initial post makes it sound :) |
|
seems like we can't continue this work (see microsoft/Windows-Containers#102) 😞 |
Well, to be specific, we can't upload any Docker image created from the MSVC Dockerfile to Docker Hub. We could keep an example template in this or another repo, which I think has a lot of value. All the other changes made by this PR should be fine, however. |
|
Without any official image to build rust binaries, I'm now cross-building my Windows container images on Linux instead: #30 (comment) |
|
To my understanding, solving rust-lang/rust#71520 would reopen the door for this PR here. This PR seems stalled because it depends on vs_buildtools.exe and redistribution of the VS Build Tools is not permitted. In turn, VS Buildtools are required because Rust uses their In most situations it's possible to use lld for [target.x86_64-pc-windows-msvc]
linker = "rust-lld"or What do you think? EDIT: This was probably too optimistic. As @ChrisDenton points out, |
|
See also this internals thread for an overview. In short, vcruntime may one day be made open source, which would help solve issues such as this, but that day isn't today. |
The template uses Windows Server Core as the base image. Nano Server was quickly attempted, but the image did not build correctly, and I didn't put any real time into figuring out why. MSVC and GNU variants are created, though due to licensing issues the MSVC variant should never be pushed to the public Docker Hub. Only Windows Server Core 1809 is supported now as that is the highest version that Github Actions or Travis supports and the Microsoft Build Tools installer doesn't support API versions older than 1709. The GNU variant could be build for older Windows versions, but this currently not implemented.
A big shoutout to @nelsonjchen (sorry for pinging you so much) for his previous work on this which acted as a basis for the eventual implementation.