JDK-8289174 : JavaFX build fails on Windows when VS150COMNTOOLS is not set
  • Type: Bug
  • Component: javafx
  • Sub-Component: build
  • Affected Version: jfx19
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-06-24
  • Updated: 2024-11-15
  • Resolved: 2024-08-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
jfx24 b05Fixed
Related Reports
Relates :  
JDK-8342733 - Remove references to compiler flags /D_STATIC_CPPLIB and /D_DISABLE_DEPRECATE_STATIC_CPPLIB in win.gradle
Description
In order to build JavaFX on Windows, it is necessary to set the VS150COMNTOOLS environment variable. Microsoft no longer sets VS<ver>COMNTOOLS by default any more, so this is a hold-over from prior versions. It's also error prone since the build will fail with an unfriendly error message for a developer who installs Visual Studio on their system and just runs "gradle".

The JavaFX build system should attempt to locate the visual studio compiler if VS150COMNTOOLS is not set.
Comments
Changeset: a8f78505 Branch: master Author: Kevin Rushforth <kcr@openjdk.org> Date: 2024-08-14 15:00:23 +0000 URL: https://git.openjdk.org/jfx/commit/a8f7850503043f616703fdfc8d0a26a00f47b7c8
14-08-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jfx/pull/1534 Date: 2024-08-12 14:21:14 +0000
12-08-2024
After the fix I'd expect the build to not *require* XXXXCOMNTOOLS to be set. We would look using this alggorithm for version in (2022, 2019, 2017) for edition in ( Enterprise, Professional, Community) for location in ("Program Files", "Program Files (x86)") if (exists c:$location\$version\$edition) { set VSDIR=c:$location\$version\$edition; break; }; if none of them work, tell the user to set the path as the value of (eg) JFX_VSDIR giving them examples. Eg "No Windows compiler found, set JFX_VSDIR, eg set JFX_VSDIR=...
26-06-2024
A bit more on the problems in genVSproperties.bat. (1) It still hasn't heard of anything later than VS2017 and falsely claims it is the official version (2) It still looks only for Professional not Community, etc (already noted above) (3) It still has mention of versions of VS (2010, 2013) so old I seriously doubt we can build with them any more - as noted above these should be purged (4) the wiki page says to set VS150COMNTOOLS if using VS 2022 which will then make the build set VSVER to 150 which only works because the .bat file is the same name IMO we should remove mention of anything older than VS2017 and declare VS2022 the 'preferred' AND 'official' compiler. And have better handling of VSVER. I'm not sure we even need it if we fix this by removing older compilers. (5) I am not sure we should remove the logic that looks for 2017, but perhaps we should look for 2019 too ? Or perhaps its already pointless to add it. We've skipped other versions, but in part that was because of the painful side-by-side dll install requirements in 2015 (?) that Microsoft eventually realised was not viable. FYI here's a page on the versions https://learn.microsoft.com/en-us/cpp/overview/compiler-versions?view=msvc-170 (6) I think that VS 2022 only has a 64 bit version - this seems to be backed up by https://learn.microsoft.com/en-us/visualstudio/releases/2022/system-requirements#visual-studio-2022-system-requirements This means no " (x86)" in the path name. (7) buildSrc/win.gradle hardcodes "2017" in names which really should be generic on at least 2017, 2019 and 2022. It also has a fall back path name used when no VS150COMNTOOLS is set for the build name which seems unlikely to work except if you have exactly that version, ie { properties -> defineProperty("WINDOWS_VS_VSINSTALLDIR", properties, "c:/Program Files (x86)/Microsoft Visual Studio/2017/Professional"); (8) The wiki page needs updating. https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX Eg the sample file for VS2019 to use as defaults is probably useless to anyone who even has that unless they have the exact patch version and the exact Professional / Enterprise / Community edition.
26-06-2024
At the same time we should cleanup the logic to remove the check for VS120COMNTOOLS or older, and also eliminate the references to the obsolete WINDOWS_DXSDK_DIR.
24-06-2022
It should first search for the version specified in build.properties (currently VS2022) and then fall back to VS2019 or VS2017 (although the latter won't work for building WebKit). Basically we should search in both %ProgramFiles% and %ProgramFiles(x86)% for: Microsoft Visual Studio\{2022|2019|2017}\{Community|Professional|Enterprise}
24-06-2022