Strategy for prebuilt windows binaries for 3.3 (Issue #25288)
PB
PBfordev created an issue (wxWidgets/wxWidgets#25288)Seeing as the first release in the 3.3 branch comes close, I think it could be a good idea to discuss possible changes in the binary release process, possibly simplifying it (besides going from supporting five MSVS versions to one).
Even if no one asked, here are my two cents on the topic.
Firstly, is there a reason to still provide 32-bit builds in 2025 and beyond, targeting Windows 7 and newer? Download stats for 3.2.7 on the website show similar numbers as for the 64-bit ones; however, seeing as they all hover around 500 for basically all compilers and architectures, I wonder how reliable/representative those are...
Secondly (and more importantly) about MinGW/GCC-based binaries. wxWidgets 3.2.7 offers prebuilt binaries for five toolchains (GCC is currently at v14.2):
- MSYS MinGW-w64 13.2
- MSYS MinGW-w64 12.2
- TDM-GCC 10.3
- MinGW-w64 8.1
- MinGW-w64 7.3
As for 1-2 (GCC vs clang debate aside), IMO, if you are using MSYS2 and don't want to build a library by yourself, you will probably use its package manager to get it. MSYS2 provided also "unstable" 3.1.x releases via pacman. Moreover, we are playing a catch-up game with MSYS2 releases of GCC. Last but not least: Incompatible msvcrt vs ucrt library builds with the latter likely being the better choice now. Is there really a point in providing MSYS2-based binaries?
As for 3-5, these compiler packages have been long abandoned. AFAIK, there are currently two maintained standalone GCC-based toolchains (nuwen had last release in 01/2024): WinLibs and niXman. I am not sure if the two have enough traction to support them.
Of course, in addition to building a library by ourselves or getting its binary from the library maintainers, we now have even on Windows popular and convenient package managers such as MSYS2 and vcpkg, covering all three compilers and probably decreasing the demand on the "official" binaries.
I am interested in hearing your thoughts and/or counter-arguments to my points?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
grika335
grika335 left a comment (wxWidgets/wxWidgets#25288)Mountain
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25288)Thanks for raising this question, this indeed needs to be decided, although mostly by the current binary maintainers, so I'd like to ping @doscott and @XPsoud (sorry if you have already noticed this).
- I agree that it should be safe to drop 32 bit binaries, people shouldn't be using them in 2025.
- MSYS2 packages indeed seem to be nice and up to date (3.2.7-1) right now. I wonder if @stahta01 who contributes to maintaining them can tell us about their plans for 3.3.0, i.e. will it be packaged for MSYS2 or will they wait for 3.4.0 before doing it?
About the download numbers: I think they're correct but they must correspond to automatic downloads (CI?), so the best strategy is probably to subtract the number of downloads of archives that we suspect are almost not used any more, e.g. MSVS 2008, which has ~7000 downloads for 3.2.6 as of right now, from those that are still used, e.g. wxMSW-3.2.6_vc14x_x64_Dev.7z which was downloaded ~17000 times, giving us ~10000 "real" downloads. To be compared with ~400 downloads in total (but I think they must all be "real") for wxMSW-3.2.6_gcc1420_x64_Dev.7z, for example.
If we can trust these numbers, then providing MSVS binaries is still useful, in spite of vcpkg etc. For gcc ones I'm less sure, the most downloaded one is wxMSW-3.2.6_gcc810_x64_Dev.7z with 8752 downloads, but I'm almost certain that 7000 of them are automatic.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Danny Scott
doscott left a comment (wxWidgets/wxWidgets#25288)Building the single VS2015 packages is trivial.
I'm turning 69 in a few months and haven't done any actual programming in 10+ years so it may be good if someone takes over before 3.4
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
PBfordev left a comment (wxWidgets/wxWidgets#25288)Just to be clear, I did not suggest dropping binaries altogether. They are still useful and MSVC ones cannot be easily obtained elsewhere (e.g., from nuget) for CI.
As for MSVS binaries... AFAICT, the compatibility is backwards, not forwards, see https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170#restrictions
So this means that for example, one cannot link an import library produced by MSVS 2022 with MSVS 2015. Therefore MSVS 2015 is needed to produce the binaries. I could no longer find the free version of MSVS 2015 (Express/Community) for download on MS website. FWIW, GitHub CI does not offer MSVS 2015, AppVeyor still does.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Danny Scott
doscott left a comment (wxWidgets/wxWidgets#25288)I would say the binaries are forward compatible. I have VS2015 installed from day 1. I found the following but haven't tried it yet.
https://archive.org/details/vs2015.3.com_enu_202102
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25288)Whether we call it backward or forward, the unfortunate reality is that we need the oldest MSVS version we want to support (i.e. 2015 right now, although we might to bump this up for 3.4.0) to build the binaries and GitHub images indeed don't provide such versions any more — and there is no equivalent of Docker for Windows in which we could run an older image, unfortunately.
So I don't have any good solution for building these binaries automatically, unfortunately.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25288)I'd like to repeat here my comment in #25289 too: I think we should use _x86_ infix for the 32-bit archives, just as we use _x64_ for the 64-bit ones. We can't change the names of the libraries for compatibility, but there should be no such concerns for the names of the downloads we provide and I think there must be quite a few people mistakenly downloading 32-bit files currently.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
PBfordev left a comment (wxWidgets/wxWidgets#25288)I would say the binaries are forward compatible. I have VS2015 installed from day 1. I found the following but haven't tried it yet.
https://archive.org/details/vs2015.3.com_enu_202102
Oops, sorry I meant forward compatibility. I downloaded and installed MSVS 2015 Community from the link above. It installs at version Version 14.0.25431.01 Update 3 and I could not find a way to update it, so it probably is the last version it has? So as long as webarchive keeps the file, we should be good and do not need to rely on MS offering the updates.
I think we should use
_x86_infix for the 32-bit archives, just as we use_x64_for the 64-bit ones.
I think you said in the first post in this thread it would be safe to not provide 32-bit binaries anymore?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25288)Oops, sorry I meant forward compatibility. I downloaded and installed MSVS 2015 Community from the link above. It installs at version
Version 14.0.25431.01 Update 3and I could not find a way to update it, so it probably is the last version it has? So as long as webarchive keeps the file, we should be good and do not need to rely on MS offering the updates.
I wonder if we could use https://github.com/mstorsjo/msvc-wine to automate setting up under Linux.
I think we should use
_x86_infix for the 32-bit archives, just as we use_x64_for the 64-bit ones.I think you said in the first post in this thread it would be safe to not provide 32-bit binaries anymore?
Yes, sure, we don't need any infix if we drop them completely. And I think nobody is using 32 bits by now, but I could be wrong about it...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Danny Scott
doscott left a comment (wxWidgets/wxWidgets#25288)It might be possible to do this directly in windows using docker if VS2019 is used as the minimum:
https://learn.microsoft.com/en-us/visualstudio/install/build-tools-container?view=vs-2019
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maarten
MaartenBent left a comment (wxWidgets/wxWidgets#25288)As for 3-5, these compiler packages have been long abandoned. AFAIK, there are currently two maintained standalone GCC-based toolchains (nuwen had last release in 01/2024): WinLibs and niXman. I am not sure if the two have enough traction to support them.
It seems Code::Blocks ships with WinLibs, see #25471.
Currently 14.2.0 (gcc 14.2.0, llvm 19.1.7, posix, ucrt, win64), but I don't know how often that updates. Maybe worth adding?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
computerix
computerix left a comment (wxWidgets/wxWidgets#25288)There have been 3 to 5 years between codeblocks releases, and CodeBlocks 25.03 has been released just 2 months ago.
So I think CodeBlocks 25.03 will be around for several years, and so will the bundled WinLibs gcc 14.2.0
(they don't re-bundle their versions with newer compiler releases).
Most sites still have the previous CodeBlocks 20.03 installed, which is still available for download and still contains bundled MinGW-w64 8.1. I hope this will die soon, but I think it will take several months until the majority has upgraded....
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
PBfordev left a comment (wxWidgets/wxWidgets#25288)I am closing since 3.3.0 is out and the discussion seems to be done.
BTW, 3.3 is available as MSYS2 packages: https://packages.msys2.org/base/mingw-w64-wxwidgets3.3
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
Closed #25288 as completed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.