Re: Outdated win32 bundle

Hi all,

In GStreamer we have been using, for a couple a years now, a build
system named cerbero to build and package the GStreamer SDK for Linux,
Windows, OS X, Android and iOS
(  and we are also using it
for continuous integration with Jenkins

I have been working in some recipes and packages repository for the
Gtk+3 build that can build and package Gtk+3 for Windows and OS X
providing native packages for those platforms that developers can use
for developing or to bundle them in their applications.

I think cerbero could greatly help Gtk+'s developers in the same way
it's being helping GStreamer:
  * A single build system for the all the platforms
  * Support for cross-compilation from linux to windows
  * Build from tarballs or git
  * Easy integration with CI systems
  * Could build Gtk with MSVC too with some changes in the VS project
files, even for CI (using autotools for the generated files and
building with msbuild)
  * Native packages for all the platforms split in runtime and development.
  * Windows: MSI based packages
  * Windows: Merge modules to bundle gtk with windows installers.
  * Windows: Integration with Visual Studio with import libraries and
pkg-config-style property sheets (this means importing a single
property sheet file to have all the search paths and libraries
variables set for you)
  * OS X: real Framework that can be drag and dropped to XCode
  * OS X: pkg files that can be easily bundled in applications.

What it can't do (yet):
  * Cross-compile the msi packages from linux to windows (might be
possible using the msitools, but we have never tried it yet)
  * Build the full stack with msvc.
  * Cross-compile gobject-introspection (it's been a while since I didn't check)

Here are some examples of what you can do:

Cross-compile gtk for windows x86:
 ./cerbero/cerbero-uninstalled -c gtk-win32.cbc bootstrap
 ./cerbero/cerbero-uninstalled -c gtk-win32.cbc build gtk+3

Build gtk from git:
 ./cerbero/cerbero-uninstalled -c gtk-win32.cbc build gtk+3-git

Hack for Windows in Linux:
 ./cerbero/cerbero-uninstalled -c gtk-win32.cbc shell
git clone gtk;
configure && make

 ./cerbero/cerbero-uninstalled -c gtk-win32.cbc fetch-package gtk-3
--reset-deps --full-reset
 ./cerbero/cerbero-uninstalled -c gtk-win32.cbc build gtk+3-git

Create the SDK package for OS X:
 ./cerbero/cerbero-uninstalled -c gtk.cbc bootstrap
 ./cerbero/cerbero-uninstalled -c gtk.cbc package gtk-3-sdk

Create the SDK package for Windows x86_64:
 ./cerbero/cerbero-uninstalled -c gtk-win64.cbc bootstrap
 ./cerbero/cerbero-uninstalled -c gtk-win64.cbc package gtk-3-sdk


2015-06-12 13:42 GMT+02:00 Emmanuele Bassi <ebassi gmail com>:

On 12 June 2015 at 12:27, anatoly techtonik <techtonik gmail com> wrote:
On Thu, Jun 11, 2015 at 4:15 PM, Emmanuele Bassi <ebassi gmail com> wrote:

Currently, we advertise ad hoc Windows builds on; those are
out of date, and lack many of the bug fixes that went into GTK.

I see two problems here:
- [ ] - doesn't say this info
- [ ] - 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:

It would be good to fix the website to reflect the reality.

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+.

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 website needs to be changed to reflect the reality of the project,
not the past.

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.

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.

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

That's possible if you build GTK+ for yourself.

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.

Telling your users to download your application; download DLLs from; 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

That's what I said above.

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.

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 — 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. if using closed source service is okay.

No, it's really not — especially if it has to run on the

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


[ ] ebassi [ gmail com]
gtk-devel-list mailing list
gtk-devel-list gnome org

Andoni Morales Alastruey

LongoMatch:The Digital Coach

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