Windows builds

[billiegoose]

I don't have the time to make a PR, but for whoever does, I wanted to suggest using dockcross. I had excellent results with it in cross-compiling clib

[Calinou]

As far as I know, if you have WINE and rcedit installed (to change the application icon and metadata), it should be possible to cross-compile Electron applications without requiring a full C/C++ toolchain.

However, I tried running gulp vscode-win32-x64 on Fedora 28 and while the build succeeds, I only get a gray window when running it on Windows.

I wonder if it would be easier to use AppVeyor instead. This could require the use of a tool like gothub to deploy build artifacts from AppVeyor and Travis CI to GitHub Releases, as Travis CI's built-in deployment tool may not be able to cooperate with other CI systems.

Edit: Deployment of builds using both Travis CI and AppVeyor's built-in deployment systems seems to work fine in trust, so it's probably not an issue.

[stripedpajamas]

@Calinou @wmhilton
I plan on using AppVeyor instead of Travis+Wine, as I have had some success with that in another project. PRs are welcome for an AppVeyor yaml file. I will try to do it in the coming days/weeks if I get some time.

[TimothyDJewell]

@stripedpajamas
Hi! I've been putting a little time into setting this up with appveyor. Today I finally managed to get a build successful (lots of polish/debug to remove), but as I've been developing in the dark, I figure a quick sanity check is in order before I invest more time polishing.
I'm still not completely sure what to do as far as packaging it up for Windows consumption. I'm thinking for the time being we'll provide just a zip file with the output contents, and let users do their own unzipping/install. Microsoft seems to provide the equivalent zip as an option of their set of downloads, though it is the least preferred. Is this in line with what you're thinking?
This will seem to conflict with the OSX logic in check_tags.sh, which appears to only check that the name element of the asset contains "zip". Do you have a preference for how we handle that? The simplest thing I see is to replace "zip" with "darwin"...

[Calinou]

@TimothyDJewell The official Visual Studio Code Windows installers are created using Inno Setup. I remember seeing the .iss file used by Microsoft to create those somewhere, but I can't find it anymore.

I think providing both options (installer + ZIP archive) is the best. Installers are better-suited for beginners (as they make it easy to add VS Code to the PATH), but ZIP archives are more suited for automated installations (e.g. when using Scoop).

[TimothyDJewell]

Thanks @Calinou! Looks like it's currently at /build/win32/code.iss. I've never done any of this before, but I'll give it a shot. I agree that matching the VS Code options is best.

[stripedpajamas]

@TimothyDJewell thanks for the work so far. Excited to see a Windows build in the near future.

Duplicating whatever MS has on their download page is definitely the route to go. It looks like they do provide a zip and an exe, the executable being preferable. Since this is all happening in Appveyor, we shouldn't have to worry about the existing build scripts used by Travis at all. Since you are able to control the Windows output file names, we can make an Appveyor equivalent of the check_tags.sh script check for those file names before building. Probably something like checking for win32 in the name, or just windows.

Let me know if I can help at all because I'm eager to get the Windows builds working as well 👍

[G-Ray]

It seems Windows ci environment is now available on travis: https://docs.travis-ci.com/user/reference/windows/

[stripedpajamas]

@G-Ray yes! I was testing it out this past weekend. Unfortunately there is currently a known issue that the build won't work at all if there are secret environment variables (https://travis-ci.community/t/current-known-issues-please-read-this-before-posting-a-new-topic/264). We have a GITHUB_TOKEN environment variable, so it isn't working yet. Once they fix that, I'm excited to see if it's easier to work with than AppVeyor.

cc @TimothyDJewell

[pavanagrawal123]

Hey I was interested in fixing the issue for Windows builds, but I see that AppVeyor is paid and Travis still has the secrets issue... Can we try using Azure DevOps? It's free for 10 parallel builds... @stripedpajamas @TimothyDJewell

[Calinou]

@pavanagrawal123 AppVeyor is free for public repositories, lots of open source projects rely on it.

That said, Azure Pipelines is worth trying since it features higher limits and supports all three major OSes.

[stripedpajamas]

@pavanagrawal123 any help is welcome and any platform is fine if it produces working Windows builds :)

[pavanagrawal123]

@Calinou whoops just noticed it says "free for open source" in big letters

@stripedpajamas sure, will try my hand at Azure Pipelines!

[pavanagrawal123]

@stripedpajamas and @Calinou I have successfully got Azure Pipelines working! 64bit builds are working on Windows :)

How do y'all suggest I publish the artifact onto GH?

[stripedpajamas]

I'm not sure how releases work in Azure. Most likely you will need a personal access token as an environment variable like we have in the Travis build. If you want you can go ahead and open a PR and then we can continue improving it together.

[stripedpajamas]

(also THANKS for your help so far, I'm very excited for Windows builds) @pavanagrawal123

[pavanagrawal123]

Alright, that's what I was thinking as well. I'll clean up a few things and submit the PR in a couple of hours!

[pavanagrawal123]

Opened #58. Still doesn't push to GH releases, but that shouldn't be too hard to solve.

[gerroon]

Any plans tfor release?

[pavanagrawal123]

It's open in a PR #58. If you want releases now you can check https://github.com/pavanagrawal123/vscodium

[gerroon]

@pavanagrawal123 Hey thanks, I will take a look at them.

[JL2210]

Is this fixed by #58?

[stripedpajamas]

@JL2210 waiting to see if the windows builds succeed and upload.

[gerroon]

@pavanagrawal123 build worked for me

[gerroon]

Any chance of getting the 1.30 Win builds?

thanks

[stripedpajamas]

@gerroon yes! I am trying to figure out why it didn't auto build. Should have them later today.

[gerroon]

@stripedpajamas did you figure out what the issue was?

[stripedpajamas]

Two things-- the build is broken and the scheduled builds don't run. Working on part 1; part 2 might not be fixable. Might need to migrate Windows builds over to AppVeyor

[pavanagrawal123]

@stripedpajamas we should be able to trigger with a webhook or something though right? also, what's broken on the builds?

[gerroon]

@stripedpajamas thanks for the follow up

[JL2210]

Any way I could help? I have a Debian Stretch system with a mingw-w64 toolchain installed.

…

On Sat, Dec 22, 2018, 5:23 PM gerroon ***@***.*** wrote: @stripedpajamas <https://github.com/stripedpajamas> thanks for the follow up — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AlC1Cef-8-f86ojAJ3jj7nKRD0U7WZf-ks5u7rDmgaJpZM4WP2Tg> .