hyperrogue
hyperrogue copied to clipboard
zenorogue
Add Travis configuration for MinGW64 builds
Based on: https://docs.travis-ci.com/user/reference/windows/#how-do-i-use-msys2
Just one -- Makefile.simple -- job for now, since that seemed to work fine locally for me. Automake-build could also be added, but not sure of its necessity.
I think that covers everything you've mentioned, except
export PATH=/C/tools/msys64/mingw64/bin:$PATH
I'm not sure of the necessity of that, TBH. It's the toolchain binary location, but I don't really know whether it's not exported already by that point. Locally, I didn't use the exact same approach, since there are special binary launchers for Windows that take care of exactly things like that I guess.
EDIT: actually, the plain make, which is recommended in most cases by MSYS2 docs, is not in this location. mingw32-make is.
I can try looking through docs to clarify.
It seems like Travis isn't happy yet: https://travis-ci.org/github/zenorogue/hyperrogue/jobs/689351528
$ # Install GLEW if asked for
if [[ "$HYPERROGUE_USE_GLEW" == "1" ]]; then
if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then
sudo apt-get install -qq libglew-dev
elif [[ "$TRAVIS_OS_NAME" == "osx" ]]; then
brew install glew
elif [[ "$TRAVIS_OS_NAME" == "windows" ]]; then
$MSYS2 pacman --sync --noconfirm --needed mingw-w64-x86_64-glew
else
exit 'Unsupported OS'
fi
fi
Refreshing environment variables from registry for cmd.exe. Please wait...Finished..
error: could not open file /var/cache/pacman/pkg/mingw-w64-x86_64-gcc-libs-10.1.0-2-any.pkg.tar.zst: Child process exited with status 127
error: could not open file /var/cache/pacman/pkg/mingw-w64-x86_64-python-3.8.3-1-any.pkg.tar.zst: Child process exited with status 127
error: could not open file /var/cache/pacman/pkg/mingw-w64-x86_64-harfbuzz-2.6.6-1-any.pkg.tar.zst: Child process exited with status 127
error: could not open file /var/cache/pacman/pkg/mingw-w64-x86_64-freetype-2.10.2-2-any.pkg.tar.zst: Child process exited with status 127
error: failed to commit transaction (cannot open package file)
ERROR: The process "gpg-agent.exe" not found.
ERROR: The process "dirmngr.exe" not found.
resolving dependencies...
looking for conflicting packages...
Packages (1) mingw-w64-x86_64-glew-2.2.0-2
Total Download Size: 0.50 MiB
Total Installed Size: 5.44 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages...
downloading mingw-w64-x86_64-glew-2.2.0-2-any.pkg.tar.zst...
checking keyring...
checking package integrity...
loading package files...
Errors occurred, no packages were upgraded.
The good news is that this seems to be exactly the error message given at https://github.com/msys2/MSYS2-packages/issues/1962 (reported 2 days ago), and so maybe if we just wait a few days everything will be back to normal and Travis will become happy?
I notice the lines
ERROR: The process "gpg-agent.exe" not found.
ERROR: The process "dirmngr.exe" not found.
in the middle there. I vaguely remember seeing the same help doc that you must have seen, re that first taskkill line at least, and deciding that it didn't seem to be needed on Travis. Did you observe that it was needed?
Added a commit fixing a quirk in SDL_gfxPrimitives.h. Pretty much the same fix was required on Arch Linux when I tried (successfully eventually) to build Hyperrogue there. Maybe there is a more "right" way, though.
Re taskkill: when installing on Windows through the standalone installer, as per this instruction (namely, section V, point 5), I did indeed experience those two programs hanging after an initial core bootstrap/upgrade. It could very well not apply to Chocolatey package -- I should probably investigate.
As for the former errors, now that I look at it more closely, it seems odd that there is no -y argument to pacman, or no initial pacman -Syu at all. To explain a bit (from what you stated elsewhere I assume MacOS is your only system; sorry if I'm explaining the obvious): -S a.k.a. --sync is the command code for all the install or upgrade operations, -y a.k.a. --refresh is a subcode for updating package database, and -u or --sysupgrade is a subcode for, well, upgrading existing packages. It's also not completely clear to me why they went for verbose versions of these commands, since in everyday use you just pacman -Syu or something like that.
EDIT: https://github.com/msys2/MSYS2-packages/issues/1962#issuecomment-630315437 This suggests that indeed an initial refresh+upgrade may be necessary.
Let's see what it thinks about this one. Also, it's a bit unexpected to me that Travis automatically pulls updates to its config even from unapproved changes, but I guess it's for the best: it lets test things more quickly.
sound of forehead slapping
I forgot that there's noone to press the Y button out there. Oops.
Yeah, I think this was in the wrong place. I can try just one more (admittedly hacky) thing, and that's to bypass Chocolatey-package initial configuration (/NoUpdate option), upgrade pacman, and then resume as usual. This might be necessary, because last update to the package was in October of the last year.
Seems like I was overly optimistic with removing the "draft" status.
For reference, this here seems to be the same kind of issue.
In case I was too oblique with my reference to https://github.com/msys2/MSYS2-packages/issues/1962#issuecomment-630258878 , I think the really important comment is this one:
Sorry for the inconvenience :/ There is some breakage today with the upgrade path from the last stable installer.
In other words, it sounds like the Msys2 maintainers broke something within the past 72 hours, and (they didn't say so but I hope) if we just wait a while they may fix it. I know how tempting it is to keep trying to solve the problem Right Now, but it may be a better use of time to just let this PR sit for a week and then pick it up again and see if it's magically fixed itself.
Your "this here" was also posted in the past 24 hours, indicating that this is a very new (and I hope temporary) upstream issue.
I believe I'd found references to the same problem from earlier than that. But you may be right still.
Sorry for commit-spam, by the way. It's sort of the only way to test, but if the latest one fails, I'll probably stop and wait for the proper fix. In my defense (quote from me earlier),
This might be necessary, because last update to the package was in October of the last year.
This was my reasoning, since there's also the matter of Chocolatey package being used.
https://chocolatey.org/packages/msys2#comment-4919416069
OK, I admit that I should've paid more attention. Looks like the problem is indeed very recent, and will probably be fixed soon.
Looks like (https://github.com/msys2/MSYS2-packages/issues/1970#issuecomment-632716190) the issue has been fixed. I should probably clean up the commits here, and try again.
It builds alright now, but the test fails due to "missing" DLL. Must be something funny going on with the PATH. Adding to the earlier question (https://github.com/zenorogue/hyperrogue/pull/116#discussion_r428178794): not only is the toolchain located at /mingw64/bin, but all related DLL should be there as well. That is to say, libstdc++-6.dll must be there, as long as mingw-w64-x86_64-gcc-libs is installed, which, judging by the log, it was.
Could the current failure https://travis-ci.org/github/zenorogue/hyperrogue/jobs/690404626 be due simply to writing ./hyperrogue instead of .\hyperrogue.exe, or some minor thing like that? It's weird that Travis doesn't give any information except "exited with 127."
Actually, it does say a bit more, it's just that for inexplicable reasons that output is disconnected from where it logically belongs: this line specifically (it's what I referred to in my last comment).
C:/Users/travis/build/zenorogue/hyperrogue/hyperrogue.exe: error while loading shared libraries: libstdc++-6.dll: cannot open shared object file: No such file or directory
EDIT: let's try something really dumb first. As for what you suggest, I think I did try spelling out the extension explicitly, but haven't yet tried the backslash. I can try that next.
At last, it works. Sure took some ugly hacks to pull off though. Now to think up a way to clean up this mess.
The newly added MinGW-autotools build fails, but if I read this correctly, it's because it's unique in the fact that it also includes rogueviz, while other builds with the same CXXFLAGS don't (-Werror, chiefly).
On an unrelated note, I don't really like how on build and test steps there have to be checks whether build-host is Windows. Would it be better if, at early preparation steps, $MINGW64 were just set to an empty string for Unices, so that all the commands could be uniformized?
And the output being out of order might not be an isolated occurence. I don't know how I feel about their workaround though.