Hi all. I've got my own builds of Gtk+ for Windows, available at: http://tesla.duckdns.org/jewelkit-1-0-released/ ( I have another build I'm ready to upload in the next week actually ). This contains perl as well as Gtk+. I make regular releases ( currently ). I also have a bunch of patches I've been meaning to submit ( fixing build issues ). In particular, the object introspection stuff is a MAJOR PITA to build on Windows, and AFAIK is impossible to build in Linux with a cross-compiler. It would be fantastic if building Gtk+ ( and bindings ) on Windows were "far less painful" ... and better yet if there were official installers ... though I guess that's asking a bit much for corner-cases like perl developers' needs :) Dan On Fri, Jun 19, 2015 at 4:20 AM, Tarnyko <tarnyko@xxxxxxxxxxx> wrote: > 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 that >>> >>> >>> Yes, 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=747742 >>> It 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 with >> description 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 to >> allow 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 >> to >> do 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 integrators >> a 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-go >> for 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 Windows >> I can try to automate the process - the script I used for Wesnoth became >> a 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-list mailing list > gtk-list@xxxxxxxxx > https://mail.gnome.org/mailman/listinfo/gtk-list _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
