Re: Outdated win32 bundle



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


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