Re: Outdated win32 bundle

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Thu, Jun 11, 2015 at 4:51 PM, Jasper St. Pierre <jstpierre@xxxxxxxxxxx> 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@xxxxxxxxx> wrote:
> Hi;
>
> On 11 June 2015 at 13:44, anatoly techtonik <techtonik@xxxxxxxxx> wrote:
>> On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi <ebassi@xxxxxxxxx> 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@xxxxxxxxx
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list



--
  Jasper
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list



--
Ignacio Casal Quinteiro
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux