All,
Just wanted to drop a note that while I have not released an installer for a bit, there is in fact work in progress.
The longer version...
The original installers used Py2.7, which was designed to use VS 2008.. which then forced packages to use the same compiler... But GR 3.7 required newer compilers... the net result was that handy tools like "pip" and most pre-built binaries were nearly useless due to ABI conflicts, and everything in those packages had to be built from scratch with VS 2015... So the Win64 build scripts have painful manual compilation of libraries never originally intended for windows, and built with VS 2015+ consistently.
THIS in work version, using python 3.x, does not have this issue, as VS 2015/17/19 are pretty much cross-compatible now and the expected compilers for Py3 versions. As a result, we can use the nifty "vcpkg" project to do most of the dependency heavy lifting, and get standard packages from pip. Plus 64-bit packages are now pretty much standard.
The good news here is that the final product will be simpler to maintain, as now windows-unique issues will be handled upstream, and the installer scripts will just need to handle GNURadio and a handful of specialized packages not found elsewhere. And for 95% of the packages, a single line of script code will add the package. So that means more rapid turnaround of releases, and inching closer to be able to integrate into a CI framework.
The bad news is that 5%. Things like the most recent numpy (1.19.4) being completely broken on windows... most of that 5% is in my personal nemesis, gobject-introspection, which is not currently supported by vcpkg, and is required by GTK. This library is a nightmare to build... but I am working to try to add it to the vcpkg ports. To add it to vcpkg of course now requires upgrading other glib components... and if I may rant for a moment, the build chain for GI in vcpkg is [sometimes]:
vcpkg calls cmake
cmake calls meson
meson calls ninja
ninja calls python
python calls C compiler to build extension
extension scans C header files to build XML files
each step making their own unique changes to the build environment, and they may or may not pass error information verbatim upstream... what could go wrong?? Right now I'm stuck with an extraordinarily helpful error "non-zero exit status 3221225781" from someplace in the gir data generation phase. It's a nightmare :).
BUT... It will eventually be completed one way or another, so wanted the community to know it's not been dropped.
Geof