Cheers.Here you have:And here you have some downstream patches:
https://bugzilla.gnome.org/show_bug.cgi?id=620566
https://bugzilla.gnome.org/show_bug.cgi?id=733535
https://bugzilla.gnome.org/show_bug.cgi?id=693531
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gobject-introspection--On Thu, Jun 11, 2015 at 5:07 PM, Jasper St. Pierre <jstpierre mecheye net> wrote:I can take a look at the gobject-introspection work. Bugzilla links?
--
On Thu, Jun 11, 2015 at 10:57 AM, Ignacio Casal Quinteiro
<nacho resa gmail com> wrote:
>
>
> On Thu, Jun 11, 2015 at 4:51 PM, Jasper St. Pierre <jstpierre mecheye net>
> wrote:
>>
>> Would it be possible for me to fund / help maintain official GNOME
>> Win32 bundles and an SDK? I'd love to improve Windows support of GTK+,
>> but I'm never sure where the status is. Last time I tried jhbuild it
>> failed on something early on -- I believe fontconfig, so that was a
>> bummer.
>
>
> Well the current status is quite good compared with how it was a few years
> ago.
> The main problems are still:
> 1. that we have lots of downstream patches still on msys2, even though I
> spent quite a lot of time pushing them upstream.
> 2. building anything out of git is a nightmare, you need a tarball or
> everything gets in your way
> 3. gobject-introspection could get quite a bit of love for windows. There
> are though some patches in bugzilla that are waiting some review.
> 4. jhbuild would require some serious work.
>
> Cheers.
>
>
>>
>>
>> On Thu, Jun 11, 2015 at 9:15 AM, Emmanuele Bassi <ebassi gmail com> wrote:
>> > Hi;
>> >
>> > On 11 June 2015 at 13:44, anatoly techtonik <techtonik gmail com> wrote:
>> >> On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi <ebassi gmail com>
>> >> wrote:
>> >>>
>> >>> The current stance of everyone involved in the Windows backend for
>> >>> GLib and GTK+ is to stop advertising binary builds for Windows — as we
>> >>> don't do that for any other platform, and nobody sticks around long
>> >>> enough to keep doing that or to set up a continuous integration build
>> >>> for GTK.
>> >>
>> >> Stop advertising == stop supporting?
>> >
>> > If I wanted to say "stop supporting", I would have said that. Not that
>> > we *ever* "supported" binary builds, on any platform. If you want
>> > commercial support, you should contract somebody.
>> >
>> > 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. 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.
>> >
>> > 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.
>> >
>> >>> Developers using the G* core platform libraries on Windows are
>> >>> strongly encouraged to use the MSYS2 distribution:
>> >>>
>> >>> https://msys2.github.io/
>> >>
>> >> Like Git? Ship 200Mb of "additional value" on top? Just for comparison
>> >> Mercurial installation is 37Mb compared with 267Mb of Git. And that for
>> >> every GTK application?
>> >
>> > MSYS2 is for developers, not for end users.
>> >
>> > You're supposed to set up the development enviroment on *your*
>> > development machine(s); once you have built your application, you can
>> > take your binary artefacts, including the DLLs you depend on, put them
>> > into an installer, and let your users download the installer — which
>> > is exactly what you should have done in the past, even with pre-built
>> > DLLs. The intended change is for application developers to get
>> > pre-built, up to date binaries using MSYS2, instead of downloading zip
>> > files from gtk.org that we cannot reliably keep up to date.
>> >
>> > 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.
>> >
>> >>> This will provide you with pre-built packages that are known to work
>> >>> and maintained. It also allows you to build your own packages on top
>> >>> of it, and create an installer from the result.
>> >>
>> >> Can GTK be cross-compiled for Windows?
>> >
>> > Yes, it can, and it routinely is.
>> >
>> >>> What the GTK team would love, on the other hand, is somebody putting
>> >>> the effort in setting up and maintaining a continuous integration
>> >>> service — similar to https://build.gnome.org — for Windows builds.
>> >>> This way we would be able to catch build regressions after every
>> >>> commit, without relying on the application developers to file bugs.
>> >>
>> >> http://www.appveyor.com/ if using closed source service is okay.
>> >
>> > No, it's really not — especially if it has to run on the gnome.org
>> > infrastructure.
>> >
>> > Ciao,
>> > Emmanuele.
>> >
>> > --
>> > https://www.bassi.io
>> > [ ] ebassi [@gmail.com]
>> > _______________________________________________
>> > gtk-devel-list mailing list
>> > gtk-devel-list gnome org
>> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>
>>
>>
>> --
>> Jasper
>> _______________________________________________
>> gtk-list mailing list
>> gtk-list gnome org
>> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
>
>
> --
> Ignacio Casal Quinteiro
Jasper
Ignacio Casal Quinteiro