Re: Outdated win32 bundle
- Date: Thu, 18 Jun 2015 20:20:09 +0200
- From: Tarnyko <tarnyko@xxxxxxxxxxx>
- Subject: Re: Outdated win32 bundle
anatoly techtonik writes:
On Fri, Jun 12, 2015 at 2:42 PM, Emmanuele Bassi <ebassi@xxxxxxxxx> wrote:On 12 June 2015 at 12:27, anatoly techtonik <techtonik@xxxxxxxxx> wrote:On Thu, Jun 11, 2015 at 4:15 PM, Emmanuele Bassi <ebassi@xxxxxxxxx> wrote:Currently, we advertise ad hoc Windows builds on gtk.org; those are out of date, and lack many of the bug fixes that went into GTK.I see two problems here: - [ ] http://www.gtk.org/download/win32.php - doesn't say this info - [ ] http://www.gtk.org/download/win32.php - doesn't have a link to the site source to fix thatYes, that's why I said:| The current stance of everyone involved in the Windows backend for| GLib and GTK+ is to stop advertising binary builds for Windows There's also a bug about this: https://bugzilla.gnome.org/show_bug.cgi?id=747742It would be good to fix the website to reflect the reality.That's not that I mean. I mean that the site will not be fixed if there is no visible way to fix that. Can we solve this problem first? Where is the site source and what is the process to add the source link (along withdescription of the site update process) to the site footer?Points that are also missing to enable me (or anybody else) to fix the situation: 1. Is it possible to make "lack many of the bug fixes that went into GTK" a link to actual list?The "actual list" is published with each release of GTK+.That means that data about all previous versions need to be updated with new fixed bugs. Is the publishing process automated enough toallow this?2. How to detect automatically that builds listed on the page are out of date?There are no new builds. The last build for Windows was for GTK+ 3.6, which, as of today, is two and half years old.The question assumes that. When the build becomes out of date?The website needs to be changed to reflect the reality of the project, not the past.Marking old releases as outdated does just that.This situation is confusing for application developers, and makes the project look bad. It also reflect badly on the great work that developers have been doing in order to make GTK work well on Windows.Editing the site with heads up on the situation and an entrypoint to change it would make it better.Indeed it would.I am glad there is no misunderstanding between us here. =) Can we now make an actionable item out of it? So that it is clear for everybody how todo this and what to do exactly as a next step.On top of that, we don't offer binary builds for any other platform, and instead rely on distributors — like Homebrew on Mac; the *BSD ports; or the various Linux distributions — to provide binary builds for them. Windows is an anomaly, mostly because there weren't good/usable software distributions in the past. This has now changed, and it's a good thing to ensure that developers on Windows get reliable, up to date software.You're speaking about Chocolatey or about Steam? =)I'm talking about MSYS2.I think that the concept of package managers for Windows is flawed,but it is just my opinion as a Windows user with 10+ years experience.MSYS2 is for developers, not for end users.Ok. Still I don't get it. I wanted a local directory install for GTK libs for compiling Wesnoth. I don't want system global install of MSYS2 - I already have MinGW unpacked locally and building with SCons. Is that possible?That's possible if you build GTK+ for yourself.But that is possible with current binary downloads. That's a regression and vendor dependency on MSYS2 project. For project like Wesnoth GTK is one of the dozen possible dependencies and exclusive requirements and processes for every dependency makes life of a build system integratorsa nightmare.There have been no binary builds of GTK+ since January 2013, but there have been five new development cycles, so if you want to use an up to date version of GTK+, your current choices for building your application on Windows are either to build GTK yourself, alongside its dependencies, or use MSYS2 and its packages.I don't want to use MSYS2. My build chains is completely unattended. Here is where I download MinGW + GTK: https://bitbucket.org/techtonik/locally/src/48cd31a64c9ec8b198e2b4c9d394d43c45d65bcd/05.wesnoth.py?at=default#cl-37 and here is where I setup it:https://bitbucket.org/techtonik/locally/src/48cd31a64c9ec8b198e2b4c9d394d43c45d65bcd/05.wesnoth.py?at=default#cl-539 Using binary installer complicates this process with no benefit.Telling your users to download your application; download DLLs from gtk.org; shove them into some directory; and, finally, hope for the best, was never a good software distribution mechanism.What about developers? I find it much better workflow when DLLs are local to the project being built rather then installed globally, because often you need to test several lib versions for testing different bugs and branches.That's what I said above.So, you can't do that with MSYS2 install and will have to rebuild the GTK from scratch anyway for that use case. That looks like a no-gofor MSYS2 for me.Can GTK be cross-compiled for Windows?Yes, it can, and it routinely is.Is there a single command to run to do this?There isn't. On Fedora you can use the mingw(32|64) toolchain packages to build your own packages.That's another problem that can be solved.- [ ] provide a single command for cross-platform build of GTK for WindowsI can try to automate the process - the script I used for Wesnoth becamea good source of copy/paste automation.But it should be compiled using MinGW, not Visual Studio, right? Because appveyor is the only known CI service (to me) that compiles the stuff with VS.Visual Studio is another beast entirely.The GNOME Foundation kindly provided us with a VM that we can use to do Windows builds — which is what Tarnyko was using — using cross-compilation.So, VM is not running Windows if we're speaking about cross-compilation, right? What happened to it?
VM still exists, but is inactive at this very moment. It used a chain of scripts to build the Win32/Win64 bundle with MinGW. Visual Studio would require a Windows machine, better not consider it until the rest works well. I fear me stepping down from the project has switched the project's concern from using the VM for releasing "bundles" to using it for hosting a continuous integration system. Anyways, a reproducible/reinstallable CI would allow you to rebuild any version of GTK+3.
-- anatoly t. _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
Regards, Tarnyko _______________________________________________ gtk-devel-list mailing list gtk-devel-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-devel-list