One of the reasons I would like to eliminate Cygwin is that I believe it causes more problems than it is worth. For example, lat time I check, there was a bunch of code in the build scripts to hack paths because Cygwin apparently wants non-Windows paths on Windows. It’s the “let’s pretend we aren’t on Windows and make a mess” strategy employed by Cygwin that I find counter-productive. (As a developer, I do like having common Un*x tools installed, but I prefer Windows ports of those tools that understand how to properly run on Windows instead of creating some virtual unix environment that doesn’t quite fit.)
I suspect a lot more build logic could be done within the Gradle scripts rather than using external tools. That would result in a more portable build experience with less places for things to go wrong. Regards, Scott > On Dec 21, 2017, at 12:14 PM, [email protected] wrote: > > 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 <[email protected]> > 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 <[email protected]> >> 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
