Just as I was about to ask Santa for a successful build Iv'e managed to do it. Here are my conclusions for Win10 without WebKit:
1. vcvars32.bat VS 2017 does not create vcvars32.bat by default, some components need to be selected. I don't know which ones exactly, I think it's "VC++ 2017 v141 toolset (x86,x64)". The easiest way is to select the whole "Desktop development with C++" workload which installs ~5.5GB of libraries and IDE tools, which might or might not be useful. 2. MSVC_VER This variable is NOT the VS version, which for VS 2017 is 15.x. I don't know what that version specifies, but it needs to be the one under "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\$VERSION$". For me it was 14.12.25827. using the wrong version causes the build to fail during the task ":graphics:compileDecoraNativeShadersWin" with the cause that a file "cl.exe" cannot be found (there are 4 of these files under the above path, I don't remember which it was). 3. env variables (chapter 1) Cygwin converts the system variables on startup. Any vars that are required in addition need to be specified with `export`. The build instructions show to export JAVA_HOME, but later under Environment Variables it is set as a system env var. Additionally, for me, using `export` in cygwin did not save them and they had to be reentered on each launch. I still don't know why, gradle was not running. An alternative was to specify them under "/home/$USER$/.bash_profile" which is ran on startup, but on Windows there can be a conflict with the newline characters (\r\n vs \n) which messes up their definition. Eventually, I settled on just specifying them as system env vars. This has the advantage of not messing with slashes and quotes because Windows allows you to navigate to the file/folder and takes care of the path. Using `export -p` can verify that the paths are set correctly. 4. env variables (chapter 2) For required files or folders it will be easier to list them and ask for full paths instead of partial paths because at the end of the day this is what the build script wants. For example: - vcvars32.bat: "C:\Program Files (x86)\Microsoft Visual Studio\2017\$EDITION$\VC\Auxiliary\Build\vcvars32.bat" - cl.exe: root folder for all files "C:\Program Files (x86)\Microsoft Visual Studio\2017\$EDITION$\VC\Tools\MSVC\$VERSION$\bin" ... This bypasses installation details. It does require to change the build script though. Haven't set up anything else yet. Merry Christmas, Nir On Sat, Dec 23, 2017 at 4:29 PM, Kevin Rushforth <kevin.rushfo...@oracle.com > wrote: > It's quite possible that Microsoft changed something in their installation > of Visual Studio. We are relying on the VC/Auxiliary/Build directory being > created as part of the (default) Visual Studio installation so we can find > vcvars32.bat. You might look in your installation and see whether that file > exists somewhere else. If it does, then point VS150COMNTOOLS to the > directory containing that bat file. > > I won't have any more time to look at it this until after the new > year...maybe someone else on the list can help? > > > -- Kevin > > > Nir Lisker wrote: > > I did set them, but... if I set them in bash they disappear the next time > I launch it, which made me think they are not being set properly for some > reason even though they appear in `export -p` immediately after. Launching > bash as admin didn't do anything (I thought write permissions issue). > > So I went to the /home/user/.bash_profile file and added the export > declarations there. Now they appear on `export -p` properly every launch. I > also did `gradle --stop` and `rm -rf build`, but `gradle clean` gives the > same error. > > Otherwise, I also noticed that the folder VS150COMNTOOLS is pointing to > does not exist. I downloaded today VS 2017 Community version 15.5.2 (which > is what I set for MSVC_VER). This is as close as it gets: > > --- > Nir@Nir-Desktop /cygdrive/c/Program Files (x86)/Microsoft Visual > Studio/2017/Community > $ dir > Common7 Licenses MSBuild Team\ Tools Xml > --- > > (no VC/Auxiliary/Build) > > Is that directory supposed to be created by some process, I needed to > select some installation package for VS, or did something change from > version 14.x to 15.x? > > Nir > > On Sat, Dec 23, 2017 at 4:14 AM, Kevin Rushforth < > kevin.rushfo...@oracle.com> wrote: > >> Thanks for the feedback...I'll note it. >> >> As for the build failure, did you install Visual Studio 2017 and set the >> two env variables (VS150COMNTOOLS and MSVC_VER) to point to it? If so, then >> it should determine WINSDK_DIR without anything else needed. >> >> -- Kevin >> >> >> >> Nir Lisker wrote: >> >> Thanks Kevin, >> >> I'm going through the process now on Win 10. >> >> A few things to note: >> - In the Platform Prerequisites/cygwin it says to make sure mercurial >> package is installed. Later, under Common Prerequisites/Mercurial it says >> "you can also install Mercurial as a cygwin package". It's not clear then >> if it's needed or optional and if it replaces or complements the other hg >> toolings. >> - The link to Tortoise should be https://tortoisehg.bitbucket.io (not >> .org). >> - Might be trivial but I would say it's worth noting that all commands >> listed there are to be ran in cygwin. >> - The hg clone command probably needs to have a note added about the >> destination folder. >> >> The problems starts after navigating to the /rt directory and executing >> 'gradle tasks' or `gradle projects`: >> >> $ gradle tasks >> :buildSrc:generateGrammarSource >> A problem was found with the configuration of task >> ':buildSrc:generateGrammarSource'. Registering invalid inputs and >> outputs via TaskInputs and TaskOutputs methods has been deprecated and is >> scheduled to be removed in Gradle 5.0. >> - Directory 'D:\rt\buildSrc\src\main\antlr' specified for property '$1' >> does not exist. >> :buildSrc:generateGrammarSource UP-TO-DATE >> :buildSrc:compileJava NO-SOURCE >> :buildSrc:compileGroovy UP-TO-DATE >> :buildSrc:processResources NO-SOURCE >> :buildSrc:classes UP-TO-DATE >> :buildSrc:jar UP-TO-DATE >> :buildSrc:assemble UP-TO-DATE >> :buildSrc:compileTestJava NO-SOURCE >> :buildSrc:compileTestGroovy NO-SOURCE >> :buildSrc:processTestResources NO-SOURCE >> :buildSrc:testClasses UP-TO-DATE >> :buildSrc:test NO-SOURCE >> :buildSrc:check UP-TO-DATE >> :buildSrc:build UP-TO-DATE >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'D:\rt\buildSrc\win.gradle' line: 93 >> >> * What went wrong: >> A problem occurred evaluating script. >> > FAIL: WINSDK_DIR not defined >> >> * Try: >> Run with --stacktrace option to get the stack trace. Run with --info or >> --debug option to get more log output. >> >> * Get more help at https://help.gradle.org >> >> BUILD FAILED in 2s >> >> --- >> >> I did not install DirectX SDK. Also the output of the above commands in >> the instructions page seems out of date compared to the contents of the >> directory... or I messed up. >> >> Any ideas? >> >> >> >>> I did a first pass over the build instructions on the OpenJFX Wiki [1]. >>> I think I cleaned up the worst of the inaccuracies, and added some >>> information that will make it easier to build. >>> >>> I'm not the best person to see whether anything important is missing, >>> though. Someone less familiar with the build should look it over and let >>> me know what I've missed. I won't be able to get back to this until >>> after the holidays and after JDK 10 RDP1 is over, but will take another >>> pass at it then and incorporate the feedback. >>> >>> -- Kevin >>> >>> [1] https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX >>> >> >
