For the record following Emmanuele mail,
you can find an example on how to create an installerhttps://git.gnome.org/browse/gedit/tree/win32
On Thu, Jun 11, 2015 at 3:15 PM, 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
--
Ignacio Casal Quinteiro
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
