Add Appveyor CI build for Windows.

[brcolow]

This PR adds support for building OpenJFX on Windows using Appveyor.

In order to make this work, the project will have to be (freely) registered with Appveyor. I personally login with my Github credentials to link a project when I use Appveyor.

Here is an example build log when using this same configuration on my test openjfx repository:

https://ci.appveyor.com/project/brcolow/openjfx/build/master%20321

Currently the builds fails on Windows, but because the test results are uploaded directly to Appveyor, we can see exactly which tests fail. Here is what the test results will look like:

https://ci.appveyor.com/project/brcolow/openjfx/build/master%20319/tests

[tiainen]

Can you please update the PR to target the develop branch instead? The master branch will be kept in sync with the official openjfx repository. The develop branch will be used to gather changes from the community which should be committed back.

[brcolow]

By default Appveyor builds all branches. You want to explicitly skip building for the master branch?

[tiainen]

No, it's perfectly ok to let it run for all branches. It probably requires the appveyor.yml file to exist in the master branch for it top work then?

If it's ok, this can be a candidate to be pulled into the official repository, together with the travis build?

[brcolow]

Yeah, it has to exist for it to run. Whether or not it is a candidate for the official repository or not, I'm not sure. Not sure if it would serve any purpose. That's up to you all. My original intention was to make it so developer's doing pull requests to this repository will get test feedback on all 3 JavaFX supported platforms to make reviewers feel more confident in merging the changes to the development branch.

[tiainen]

Ok, merging it into develop will at least provide that then, since PRs will be targeted to the develop branch. We can always fine tune later if the setup turns out to be suboptimal?

[brcolow]

Yes, definitely. And there is room for improvement for sure. Especially with respect to the test result uploading. I left some comments about low-hanging fruit. But the important thing for now, IMO, is that it works.

[bourgesl]

As I already pushed the travis CI in the master branch (maybe too quickly), I am in favor of doing the same for Appveyor CI, as travis CI do not have proper windows support.
I do not expect any conflict from such CI only changes in the future.

[bourgesl]

To be clear, I propose to push in the master branch on github ONLY CI scripts only needed on the github side.
Such CI changes related to the github repo should not be pushed into OpenJFX mercurial, so it should not cause any conflict with the master synchronization from OpenJFX hg server.

[tiainen]

It will cause our automatic sync job to fail, but if it doesn't happen to often, it's ok I guess.

[bourgesl]

Ok sorry, then.
So you got into troubles after my push of the travis CI PR ?
Will the synch script fail only once or every time it runs ?

[tiainen]

No worries, it requires a manual intervention. The job is not designed to fetch and merge changes that are done on github as well. It only synchronizes the changes from the mercurial repository. The scripts are taken from AdoptOpenJDK: https://github.com/AdoptOpenJDK/openjdk-build/tree/master/git-hg, especially the setup.sh and update-without-modules.sh scripts.

[bourgesl]

Ok, so let's approve the PR !

Is the Appveyor application already enabled on this repository (credentials) ?

Any objection ?

[johanvos]

I'm ok with doing the CI on both master and develop.
I doubt it is needed on master, as that is 100% code from OpenJFX, but it doesn't hurt.
And indeed, the CI scripts are the only things we should add to the master branch.

[tiainen]

Ok, I've linked the project with appveyor as well now. So we're good to go.

[bourgesl]

Thank you !

[tiainen]

The appveyor test has been run, but fails with this:

C:/jdk9/include\jni.h(39): fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory
:graphics:compileDecoraNativeShadersWin FAILED

I don't know if this needs to be fixed in appveyor.yml or in the appveyor project settings.

[bourgesl]

I have found in the log:
'"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\vcvars32.bat"' is not recognized as an internal or external command,
operable program or batch file.
...
Converting path 'C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.12.25827/bin/HostX64/x64/cl.exe' via cygpath to C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.12.25827/bin/HostX64/x64/cl.exe
"
Maybe the paths have changed ?

So it should be:
"C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/vcvars32.bat" ??

[bourgesl]

According to
https://www.appveyor.com/docs/lang/cpp/#visual-studio

Line:
call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" amd64

Should be:
call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat"

Is it 32 or 64 bits builds ?

Any idea, @brcolow ?

[brcolow]

Hm that's strange. The "amd64" argument to "vcvarsall.bat" specifies building x64 for a x64 machine (i.e. no cross-compilation see: https://msdn.microsoft.com/en-us/library/f2ccy3wt.aspx) which is what we are doing AFAIU.

[brcolow]

Where is the appveyor for this repository? I tried https://ci.appveyor.com/project/javafxports/openjdk-jfx - doesn't work. I want to inspect the logs to try and help.

[bourgesl]

CI results are indicated in commits with links to travis & appveyor, do you see the X mark (click on detais)

https://ci.appveyor.com/project/javafxports-github-bot/openjdk-jfx/build/master%201

[brcolow]

I will open a new PR and work on this issue.