The host win32builder.gnome.org seems dead and so host the GTK+3 bundle we use to test builds for Windows cross-compilation on our own. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1931
-- Commit Summary --
* Update link to GTK+3 bundle for test builds to self-hosted version
-- File Changes --
M scripts/cross-build-mingw.sh (2)
-- Patch Links --
https://github.com/geany/geany/pull/1931.patch https://github.com/geany/geany/pull/1931.diff
Err, I would rather grab the latested mingw package and use that.
I mean msys2 package.
And to elaborate: the gtk 3.8 zip has no relevance since the releases are msys2 based. Travis CI should follow what we actually use to release as close as possible.
@eht16 will our servers manage the extra workload from auto-building PRs, assuming we/I get back to regular development workload? I was working on something similar but wanted to try and cache the bundle on Travis so we don't put that burden on us, but if it's irrelevant we should just download it at least for now.
@kugel- Yes, we should use the same setup ideally, I just am no knowledgeable on how to do that. And in the meantime, it's better to have *some* Windows build than none, even if it's not perfect. Currently the Windows build mostly tests the Win32 parts, and the parts that could be unportable.
Currently the Windows build mostly tests the Win32 parts, and the parts that could be unportable.
"Tests" is a bit generous, tests it builds is really all, but yeah, some is better than none, or disable win so all Travis results don't show as failed.
This PR was rather meant to get Travis CI working again quickly instead of revamping the way we build for CI.
@kugel- : Do you have already any idea how to get the necessary MSYS2 packages on a Linux host? We would find a way to "port" the `gtk-bundle-from-msys2.sh` to Linux I guess and the hard part is probably substituting `pacman`.
@b4n do mean handling with "extra workload" serving the bundle downloads to Travis? Or rather replacing Travis and perform the CI builds on our servers? If the former, that's easy. If the latter, I'd rather use a separate VM for that but it won't be a problem.
@eht16 I just meant the extra download on each Travis CI run. I wasn't suggesting we do the CI ourselves, which would probably be theoretically cool, but I don't think we have the manpower to maintain that, otherwise we'd already be running GitLab and all ourselves :)
Ok. As said, the extra downloads are completely fine.
Merged #1931 into master.
I restarted PR builds that were failing, they should be back we relevant results soon.
github-comments@lists.geany.org