I did not try Tom's build instructions however I can contribute that having Cygwin on Windows 7 and following the build instructions as posted on the JavaFX build instructions page is not suffcient to result in a successful build. 

The exact error messages I was receiving I posted earlier .

 
On Thursday, December 21, 2017 3:08 AM, Michael Ennen <mike.en...@gmail.com> wrote:
 
Thanks for the tip, Tom. I understand that Cygwin is a dependency of
building on Windows but didn't
know that the properties are only configured on a cygwin shell.

I have a pseudo-goal of removing the Cygwin dependency from building
OpenJFX on Windows and
I wonder why Cygwin is necessary for setupTools to work? I see other
obvious places in the build
files that would only work on Cygwin, but am unclear as to why the
properties would not be set
in cmd.exe or Powershell.

Thanks again for the clarification.

On Thu, Dec 21, 2017 at 1:04 AM, Tom Schindl <tom.schi...@bestsolution.at>
wrote:
 
Hi Michael,

I did not had to setup any special variables and documented my steps at
https://github.com/BestSolution-at/openjfx-build.

I had trouble myself initially but the reason was that I ran the "gradle sdk" command from within a MSDOS-Shell but you really need to run it within
cygwin.

Tom


On 21.12.17 06:40, Michael Ennen wrote:
 
Some people were reporting that Windows builds are difficult to setup.
I think this is due to the fact that the call to setupTools in
buildSrc/win.gradle
is in fact not working correctly.

Invoking buildSrc/genVSproperties.bat directly prints the correct
properties.

However adding some debugging to setupTools it is clear that something is
very wrong
with it. This is the result:

WINDOWS_VS_DEVENVDIR=
WINDOWS_VS_DEVENVCMD=/VCExpress.exe
WINDOWS_VS_VCINSTALLDIR=
WINDOWS_VS_VSINSTALLDIR=
WINDOWS_VS_MSVCDIR=
WINDOWS_VS_INCLUDE=
WINDOWS_VS_LIB=
WINDOWS_VS_LIBPATH=
WINDOWS_VS_PATH=;<SNIP ENTIRE SYSTEM PATH>
WINDOWS_VS_VER=120
WINDOWS_SDK_DIR=
WINDOWS_SDK_VERSION=

This is the reason people are needing to hard-code values for the
properties
below the call to setupTools.

I am trying to debug what is actually wrong with setupTools but so far not
making much
progress. I tried this on my local Windows 10 machine and Appveyor VMs and
the result
is the same. I also read at least two mails in this list about needing to
hard-code the
properties, I am assuming it is for the same reason.

I will try and figure out the reason but wanted to at least make this
issue
more concrete.

 

--
Michael Ennen

Reply via email to