add workflow doing windows builds with qt5/6 and osgeo4w dependencies

[jef-n]

• remove unused osgeo4w and NSIS packaging files and disabled azure-pipeline build
• integrate osgeo4w patches currently used for qgis-qt6-dev (superceeds changes to support msvc builds with qt6 #56980)
• also adds pr comments to artifacts and dashboard test results

[nyalldawson]

@jef-n I don't think this will work for pull requests made from forks -- the workflow won't have the permission to create comments on the qgis repo. That's why I had to go via the two workflow approach for the ming artifact comments...

[nyalldawson]

@jef-n @m-kuhn @MehdiChinoune

If we're adding two windows builds here + 1 from #57414, can we at least drop the existing mingw64 and msys2 workflows? I think 5 separate windows builds is tending slightly toward overkill 🤣

[github-actions]

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit beea934)

[m-kuhn]

@jef-n @m-kuhn @MehdiChinoune

If we're adding two windows builds here + 1 from #57414, can we at least drop the existing mingw64 and msys2 workflows? I think 5 separate windows builds is tending slightly toward overkill 🤣

😆 I agree

I also think the user communication should be quite clear in what should be tested. I.e. the build that is becoming the stable artifact (at the moment qt5) should be most prominent and everything else can be in small print/collapsed etc. Ideally everything in a single comment to not clutter the communication in the PR's with too many comments.

[troopa81]

If we're adding two windows builds here + 1 from #57414, can we at least drop the existing mingw64 and msys2 workflows? I think 5 separate windows builds is tending slightly toward overkill 🤣

I agree. And do we really need even 3, it's gonna overload the CI pipeline for basically building the same code with the same compiler. Can we not have qt5 with osgeo4w and vcpkg for qt6 ?

[3nids]

I agree. And do we really need even 3, it's gonna overload the CI pipeline for basically building the same code with the same compiler. Can we not have qt5 with osgeo4w and vcpkg for qt6 ?

+1
One thing is that we are always fighting with the cache. We need to lower the number of workflows using cache as much as possible.

[jef-n]

why do we need vcpkg?

[troopa81]

why do we need vcpkg?

I am not expert with vcpkg but IMHO I see a lot of advantages:

• It's native on Windows and supported by Microsoft
• There are a lot of already packaged libraries which avoid the burden to have to package everything ourselves
• It works well with CMake
• All the build instructions can live in QGIS repository as showed in Windows Qt6 builds based on vcpkg  #57414, easing the contribution process and consistency with source code

There is a more thorough explanation on why vcpkg on the related QEP.