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.

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.

Could you put "Co-authored-by: Nelson Chen <crazysim@gmail.com>" at the end of the commit messages where I contributed to the Dockerfiles?

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 athttps://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 ofthis 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 createdmicrosoft/Windows-Containers#102

I createdmicrosoft/Windows-Containers#102

Thank you for that. My free time suddenly disappeared last week and this fel 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 (seemicrosoft/Windows-Containers#102) 😞

seems like we can't continue this work (seemicrosoft/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, solvingrust-lang/rust#71520 would reopen the door for this PR here.

This PR seems stalled because itdepends on vs_buildtools.exe andredistribution of the VS Build Tools is not permitted. In turn, VS Buildtools are required because Rust uses theirlink.exe as default linker. Withrust-lang/rust#71520, VS Buildtools would no longer be required. Instead, Rusts copy oflld would be used. Such an image would be good for public upload.

In most situations it's possible to uselld forx86_64-pc-windows-msvc by now. We could do some preliminary trials by setting

[target.x86_64-pc-windows-msvc]linker ="rust-lld"

orCARGO_TARGET_X86_64_PC_WINDOWS_MSVC_LINKER="rust-lld".

What do you think?

EDIT: This was probably too optimistic. As@ChrisDentonpoints out,link.exe is not the only dependency. While mostrust-lang/libc functions are provided via ucrtbase (distributed with windows), a few symbols are still required from vcruntime.

See alsothis 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.

In short, vcruntime may one day be made open source, which would help solve issues such as this, but that day isn't today.

It looks like the Microsoft team that was pushing for this has abandoned the effort. See the paragraph at the bottom ofthis comment.