Well, I made a tiny bit of progress in understanding the error message when downloading plugins on Windows. The new builds give better error messages, e.g.
Error while extracting: Warning: (Unsupported ZIP compression method (8: deflation))
As far as I can tell, this means that on Windows, the libarchive code isn’t able to find zlib which handles gzip or zip files.
On the other hand, I have no idea why that’s happening right now. (e.g., it builds okay, but perhaps isn’t including zlib DLL in the install?)
One thing I’d like to learn is how to use vcpkg on Windows to install some of the pre-requisites like zlib and libxml2. (And maybe VTK?) This is what we do on Mac and Linux, and it saves a bunch of time since we don’t need to build the same code again and again.
@brockdyer03 - have you used vcpkg to install things on Windows?
It looks like we could potentially use it for:
zlib
libxml2
libarchive
eigen
Considering the download bug seems to be a zlib / libarchive issue, I’d love to just install a few things with vcpkg and get the appropriate dll bundled in the release.
On the vcpkg end, I’ve never used it for anything as I don’t do much development outside of Python and Fortran (and that’s always on the supercomputer I use).
Realistically though I think a bigger issue is that debug builds are still not possible on Windows, which seems to stem from zlib having a weird bit of naming stuff going on in the Cmake files. I think there have been other reported issues with it though, but I can’t recall. Perhaps trying out a different compression library would be useful?
I’ll take another crack at getting a debug build going again. If this can start working I might be able to look into fixing whatever is wrong with building with Qt6 too.
Same error as my previous attempts to get a debug build. Somewhere in the cmake zlib gets renamed or there’s an alias that changes some files from zlib.lib to zlib1.lib, or zlibd.lib and zlibd1.dll so I get the error
Error copying file "C:/Users/Brock/Desktop/openchemistry_debug/prefix/lib/zlib.lib" to "C:/Users/Brock/Desktop/openchemistry_debug/prefix/lib/zlib1.lib".
If I recall correctly it’s something like this happens fine in Release mode, it just renames everything to zlib1, but the debug build doesn’t get all of the files renamed since it needs to make the PDBs.
Oh, I found out why it’s zlib1 - it’s for compatibility purposes. From the zlib CMakeLists.txt:
option(ZLIB_INSTALL_COMPAT_DLL "Install a copy as zlib1.dll" ON)
In any case, I’m going to tweak the Windows build instructions on the website to use vcpkg since it gets around all of this. I haven’t done a Debug build, but I’m going to guess it’ll work. (After all, MS maintains the zlib package for vcpkg and it’s included in a bunch of others.)
I got the vcpkg build working mostly with Debug. The only issue is a bunch of linkage errors when building avogadroapp. I’m not exactly sure what to do about this, but I figure you might have some ideas with this output.
You should be able to do something like ccmake . in the main openchemistry directory to turn it off. I think that should also turn it off in avogadroapp but you may need to do it there as well.
To be clear, I set -DUSE_CONNEXION3D=OFF in the configure step, I didn’t go for the ccmake . in the main directory. If that also should happen I can give that a go
I think the next step anyway is getting the Qt6 build on Windows going and setting up a GitHub debugging build (e.g., Qt6 Windows in both Release and Debug configs).
I’m guessing that will reveal whatever is happening for your build as well?
I tried a few months back to get a Qt6 build going on any level, and while I don’t have the direct outputs anymore, I do remember it failing miserably during the configure step. It was some error I couldn’t track down even after a few days of trying, but since then I’ve just completely ignored trying to get it set up for Qt6 entirely.
I’d be very interested in seeing how you’d get a Qt6 build going, since it would add a lot of nice QOL features for Windows users (I’m beyond excited for dark mode).
Hopefully once that is all sorted any remaining errors in the Windows debug build can be fixed and I can actually try to fix some bugs (I have no clue how anyone could do any debugging without a debug build).
The first step will simply be to zip up the prefix directory without an installer, so anyone should be able to try that out before I figure out how to get an installer working.
Avogadro already builds successfully on Windows with Qt6, the GitHub Actions runs have been completing successfully (I think) ever since the Qt6 build script was added. See e.g. this recent run.
As Geoff says, the stumbling block for the GitHub builds is not that it doesn’t build, it’s that it’s not yet being packaged up into a format that people can download and use (or even just test).
So far as I can tell, the issues you’ve had with building don’t seem to arise on the GitHub runners. That’s not to say that the problem must be you/your machine, it could well be an issue with Avogadro’s build process that just only causes a problem on some systems.
I suspect your issue is one of configuration, which has always seemed to be a special challenge on Windows. But if things have to be configured a certain particular way we also need to work that out so we can add it to the build guide. Like, even if Geoff gets an installer sorted and GitHub Actions can give us Windows binaries to release to users, it’s still pretty unsatisfying if an open source project can’t be built by anyone other than an automated runner. And it completely blocks you from contributing to the code, which is a real shame.
@brockdyer03 - I’ve seen some guides on submitting to the MS Store, which would be cool. But IIRC it would be good to have an .msix installer as well, right (e.g., instead of an NSIS exe installer)?
The executable in that zip doesn’t work. Interestingly enough I’ve actually been able to get a build finished with Qt6, however the executable I get fails to launch for the exact same reason that the one in the zip failed. It may be on my end, but the issue is with some missing .dll files.
Earlier when I was working on my own build and trying to get things sorted, I managed to get a full list of missing .dll files by just creating dummy files until it finally errored about something other than a missing file. The full list is here:
Qt6OpenGLWidgets.dll
Qt6Network.dll
Qt6OpenGL.dll
Qt6Widgets.dll
Qt6Gui.dll
Qt6Core.dll
Qt6Concurrent.dll
Qt6Svg.dll
libb2-1.dll
libdouble-conversion.dll
libicuin75.dll
libicuuc75.dll
libpcre2-16-0.dll
Interestingly enough though, the build went through without any errors on my end, and I couldn’t find any reason that those .dll files should be missing.
To your question about the MS store, I wouldn’t really know much about it since I try my best to avoid using it. For some unknown reason it seems insistent on putting anything I install into the most obscure locations possible, and generally is just a bit more hassle to me than downloading and installing from the website.
With Qt5, our CMake setup did a bunch of “grab the needed libraries and put them in place.” It looked like most things were in the zip, but we probably need to use windeployqt to get everything set straight. (I’ve been working with macdeployqt for the Qt6 bits.)
My question was more “if I create an msi or msix” is that sufficient for an installer, or should I keep the NSIS somehow?
The MS Store is probably somewhat useful for some folks, since it aids discovery, and MS will “sign” it to get around the installer warnings.