build on win10 fails

[elect86]

I guess the build.gradle is based on some out-dated configuration

Useless to say, I followed to the letter the instruction to build it

However this step looks wrong:

Microsoft DirectShow header files – If you build media you will need the DirectShow header files from the Microsoft Windows SDK v7.1, installed in its default location of "C:\Program Files\Microsoft SDKs\Windows\v7.1".

The installation of Microsoft Windows SDK v7.1 will not produce anything in that location. The closest I get is:

    Directory: C:\Program Files (x86)\Microsoft SDKs

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       06/09/2018     17:54                ClickOnce Bootstrapper
d-----       06/09/2018     17:54                Portable
d-----       06/09/2018     17:57                Windows Kits
d-----       06/09/2018     17:58                Windows Phone

This is my work so far:

• WINSDK_DIR problem, for some reasons, this isn't set even if VS150COMNTOOLS and MSVC_VER are properly set, according to Kevin. Fixed by manually defining it, as Nir just said the very next comment, before the nullability check:

  
  def WINDOWS_SDK_DIR="C:/Program Files (x86)/Windows Kits/10"

if (WINDOWS_SDK_DIR == null || WINDOWS_SDK_DIR == "") { throw new GradleException("FAIL: WINSDK_DIR not defined"); }

- `$winSdkBinDir` expects to be the directory where `rc.exe` and `fxc.exe` are. On an updated configuration, this is:
`def winSdkBinDir = "$WINDOWS_SDK_DIR/Bin/10.0.17134.0/x64"`

The last problem, the one which I cant fix, is

Task :graphics:compileDecoraNativeShadersWin FAILED FAILURE: Build failed with an exception.

• What went wrong: Execution failed for task ':graphics:compileDecoraNativeShadersWin'. java.util.concurrent.ExecutionException: org.gradle.process.internal.ExecException: A problem occurred starting process 'command '/VC/BIN/amd64/cl.exe''

On an updated configuration, cl.exe is under C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\bin\Hostx64\x64

How can I quickly fix that? That is, where is /VC/BIN/amd64/cl.exe defined?

[elect86]

In win.gradle:

def msvcBinDir = "C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.15.26726/bin/Hostx64/x64"

Now I get tons of:

> Task :graphics:jar SKIPPED
SSEBlend_EXCLUSIONPeer.cc
SSEBlend_SRC_ATOPPeer.cc
C:/Program Files/Java/jdk-11.0.1/include\jni.h(39): fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory

[elect86]

No idea why, but suddendly it works.

Although I can run test fine from console, but not from within Idea, I get some errors in the ide, like

cannot resolve import com.sun.prism.impl.shape.NativePiscesRasterizerShim; // what is there is NativePiscesRasterizer

or

Error:(41, 31) java: module not found: javafx.base

requires transitive javafx.base; // in module-info.java

[elect86]

No idea why, but suddendly it works.

Although I can run test fine from console, but not from within Idea, I get some errors in the ide, like

cannot resolve import com.sun.prism.impl.shape.NativePiscesRasterizerShim; // what is there is NativePiscesRasterizer

or

Error:(41, 31) java: module not found: javafx.base

requires transitive javafx.base; // in module-info.java

[nlisker]

PR #276 changed the build.gradle file about 2 days ago, so the instructions could be outdated. @brcolow, could you updated the instructions for Windows?

Although I can run test fine from console, but not from within Idea

Ask on the mailing list. IDEs might not have caught up with the recent Java changes yet, so they require some configuration.

[brcolow]

AFAIU #276 changed the Powershell build script - not the build.gradle file. Perhaps you are asking if we should update the wiki instructions to inform people about the powershell build script?

[nlisker]

Ah, my mistake, I thought it was the gradle script for some reason. We can update the wiki to inform about the ps script anyway.

So I don't understand what the initial problem with the current instructions was.

[elect86]

Just a small update, to sum up, to fix the build on win10 one should just add these two lines:

def WINDOWS_SDK_DIR="C:/Program Files (x86)/Windows Kits/10"
def WINDOWS_SDK_VERSION="10.0.17763.0"

After setupTools() in win.gradle

You may want to add this into the wiki

[kevinrushforth]

You may want to add this into the wiki

This doesn't seem the best workaround. It should be possible to get everything to work without needing to modify build.gradle or buildSrc/win.gradle.

[elect86]

Yeah, the right way is to fix directly build.gradle and/or buildSrc/win.gradle, but I'm not an expert

My tips were meant to be for the users to get a successful build in the meanwhile

[kevinrushforth]

It is always possible that you have discovered a bug that needs to be fixed in the gradle build files, but I'm still not sure why it doesn't work for you to set the environment variables before running gradle. One thing to check (and maybe you already have) -- are you running the gradle daemon? It is enabled by default and will prevent any changes to env variables from being picked up by gradle until the next time the daemon is stopped.

[elect86]

How can I check that?

[kevinrushforth]

You can run gradle --stop which will stop any running daemons and tell you whether or not it did.

[nlisker]

@kevinrushforth Is the step

Microsoft DirectShow header files – If you build media you will need the DirectShow header files from the Microsoft Windows SDK v7.1, installed in its default location of "C:\Program Files\Microsoft SDKs\Windows\v7.1".

still needed? I don't remember doing it. If the destination C:/Program Files (x86)/Windows Kits/10 is a current replacement for the one in the instructions then it exists without the above step on my Win10.

[kevinrushforth]

The Microsoft Windows SDK v7.1 is still needed when building media, that is, when passing the -PCOMPILE_MEDIA=true option to gradle. It has the DirectShow base classes that are used when compiling the gstreamer implementation for Windows.

[elect86]

Indeed, I re-cloned once again (it's my daily task now :p)

Stopped the gradle daemon and build.. flawless

thanks guys and sorry for the troubles

[kevinrushforth]

I checked the gradle bug tracker, and it look like they might have fixed this in gradle 4.10, but in the mean time, disabling the gradle daemon is the best advice. You can put the following in your HOME/.gradle/gradle.properties file to disable it completely (which is what I do).

org.gradle.daemon=false

[Eng-Fouad]

For me, build/windows_tools.properties was not set correctly because %VS150COMNTOOLS% was pointing to VS 2017 Professional while I have VS 2017 Community. Just adding the following line to buildSrc/genVSproperties.bat solved the problem for me:

set "VS150COMNTOOLS=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Auxiliary/Build"

Or set it via environment variables.

[palexdev]

This project has the worst build system I have ever seen Requires Cygwin, the path detection is completely useless, and I keep getting WINSDK_DIR not defined, not matter what I do The only workaround is to set the paths manually in the gradle file

[nlisker]

@palexdev You're at the wrong repo, look at the README.

This is the right one: https://github.com/openjdk/jfx

[palexdev]

@nlisker I know but the idiots disabled issues there

EDIT: Since this issue is pretty common and many others could get here in search of a solution, I found it here: JDK-8266396
Download the jfxbuild2.env file and move it to the main jfx repo folder, modify it if needed (I deleted all the lines related to Ant, Gradle and JDK because they are already configured for me), open Cygwin, execute . ./jfxbuild2.env, now you can start gradle and build, ./gradlew build