[QtWebEngine] - Fix build failure

[heydojo]

This commit fixes an issue where the build fails on X86_64 Windows 10 Pro with a message similar to: 'PATCHES no such argument' printed to the console output.

It also makes a few small changes for sanity. Build trees for QtWebEngine come in at between 40GB-50GB and the minimum recommended RAM size for building Chromium according to google is 8GB. The port shouldn't be building debug by default due to it's size and the fact that you likely only want debug if you are a Qt developer or are working on vcpkg. The options "" is intentionally left blank due to the fact that it allows the string -webengine-proprietary-codecs to be easily be added in case you have licences for that kind of thing. Without that option enabled, many html5 videos do not work in QtWebEngine. Maybe adding a configuration switch for proprietary-codecs is something to think about for the future?

Enjoy!

From the build output here:

`Running configuration tests...
Checking for architecture supported... yes
Checking for bison... H:/vcpkg/installed/x64-windows/tools/qt5/mkspecs/features/qt_configure.prf:413: Unexpected return value from test 'ensurePathEnv': H:/vcpkg/buildtrees/qt5-webengine/src/gnuwin32/bin/bison.exe.
yes
Checking for submodule initialized... yes
Checking for build path without whitespace... yes
Checking for platform supported...
Checking for gperf... H:/vcpkg/installed/x64-windows/tools/qt5/mkspecs/features/qt_configure.prf:413: Unexpected return value from test 'ensurePathEnv': H:/vcpkg/buildtrees/qt5-webengine/src/gnuwin32/bin/gperf.exe.
yes
Checking for flex... H:/vcpkg/installed/x64-windows/tools/qt5/mkspecs/features/qt_configure.prf:413: Unexpected return value from test 'ensurePathEnv': H:/vcpkg/buildtrees/qt5-webengine/src/gnuwin32/bin/flex.exe.
yes
Checking for python2... H:/vcpkg/downloads/tools/python/python-2.7.16-x64/python.exe
Checking for 64bit compiler... yes
Checking for winversion... yes
Checking for jumbo build merge limit... 0
Checking for d-bus... no
Checking for fontconfig... no
Checking for libdrm... no
Checking for system ninja... yes
Checking for xcomposite... no
Checking for xcursor... no
Checking for xi... no
Checking for xtst... no
Checking for embedded build... no
Checking for node.js... no
Done running configuration tests.

Configure summary:

Qt WebEngine Build Tools:
Use System Ninja ....................... yes
Use System Gn .......................... no
Jumbo Build Merge Limit ................ no
Developer build ........................ no
Sanitizer .............................. no
Qt WebEngineCore:
Embedded build ......................... no
Full debug information ................. no
Pepper Plugins ......................... yes
Printing and PDF ....................... yes
Proprietary Codecs ..................... yes
Spellchecker ........................... yes
Native Spellchecker .................... no
WebRTC ................................. yes
PipeWire over GIO ...................... no
Geolocation ............................ yes
WebChannel support ..................... yes
Kerberos Authentication ................ yes
Extensions ............................. yes
Node.js ................................ no
Qt WebEngineQml:
Support Qt WebEngine Qml ............... yes
UI Delegates ........................... yes
Test Support ........................... no
Qt WebEngineWidgets:
Support Qt WebEngine Widgets ........... yes
Qt PDF:
Support V8 ............................. no
Support XFA ............................ no
Support XFA-BMP ........................ no
Support XFA-GIF ........................ no
Support XFA-PNG ........................ no
Support XFA-TIFF ....................... no
Qt PDF Widgets:
Support Qt PDF Widgets ................. yes

WARNING: Building without node.js will disable some features of QtWebEngine DevTools.

Qt is now configured for building. Just run 'nmake'.
Once everything is built, you must run 'nmake install'.
Qt will be installed into 'H:\vcpkg\installed\x64-windows'.

Prior to reconfiguration, make sure you remove any leftovers from
the previous build.`

Also noticed for the future:

WARNING: Building without node.js will disable some features of QtWebEngine DevTools.

Feel free to edit this pull request away to suit.

[JackBoosY]

Ping @Neumann-A for review this PR.

[JackBoosY]

Please bump the port version. See documentation.
Also please run command vcpkg x-add-version --all then commit the changes.

[heydojo]

@JackBoosY
Please use the @ tag if you want to talk directly. 👍
I don't know if you were trying to talk directly to me but I have tried to answer you below. I had to guess.

Please bump the port version. See documentation.
Also please run command vcpkg x-add-version --all then commit the changes.

@JackBoosY
Please feel free to do this. The merge is a bug fix not a new version. Therefore it's in your court if you want to do it. The merge request stands, although I logged in to this site just now to delete the tree it is in. It will remain available for at least another month. Take it or leave it. I personally don't stand to gain anything from it as I maintain my own fork. I won't hold it against anyone if it doesn't get merged. I'm past caring at this point.

I honestly can't stand Github any more and only logged in the other day to push this merge. I was in a good mood and wanted to see if this site had got any worse than I remember. Unfortunately, it has. The whole site now gives me a migraine. And because of that, it is unlikely I will be around here again. Sorry.

There is something else to add though.
Someone (that's not me) should add to the port something which stops vcpkg building the QtWebEngine port before the configure stage if vcpkg's root folder isn't at the very tip of a drive. Paths such as: C:\12345\abcde\vcpkg\ are too long and will not work. The build will fail in that case when building on Windows 10. Even if you have NTFS long path names set. A short path must be used, one such as: C:\a\vcpkg\

I know that the port prints a warning to the console output if the path is too long but the port should really go further and stop the build entirely if it detects that the path is too long because the build will definitely fail. Not only that, it will wait until at least 3 1/2 hrs have passed to cryptically announce it's failure without it being obvious that ninja could not find a file because the path was too long.

[heydojo]

Closing. Maintainers here seem to ignore discourse and prefer to ship a broken port instead of accepting a merge request.
I wouldn't like to speculate if this is cultural or not but I won't be back and I won't be offering merges at all again in the future.

[JackBoosY]

@heydojo Sorry for that, #16770 will fix this.