Re: Fwd: Plans for GTK+ Bundles for win32 and win64?

[dieterv <dieterv optionexplicit be>]

On Thu, 08 Sep 2011 12:25:25 +0100, Martyn Russell wrote:
> On 08/09/11 11:39, Alberto Ruiz wrote:
> > That's a really bad idea for several reasons. First, we don't have 
> > the
> > resources to test ABI compatibility on windows, there has been cases
> > where some versions have crashed windows apps.
>
> You mean app X uses GTK+ version A and version B is on the system =
> BOOM right?
>
> That's really about getting the package management/version management
> right IMO. Right now everyone has to do that themselves or bundle it 
> -
> which is far from ideal.

At least bundling everything with my app let's me sleep at night, 
knowing
some unknown installer out there is not going to break my stuff which 
has
taken countless hours to build.

And it also leaves me (with my packagers hat on) enough flexibility to
just drop in a new revision of say GTK+ (maybe even a local version 
testing
a patch I built with my developers hat on, before pestering people on 
bugzilla),
launch some script and presto, new installer for my program is built.

Having a shared "runtime" leads to extremely hard to debug situations 
as
the shared part is in a continues state of "unknown": Who has done what
to it? Why? Been there, done that, moved on :)

> > Second, Windows is not as good at managing shared .dlls as Linux is. 
> > It
> > can become a nightmare. You need to either wire up the Side by Side
> > plumbing or mess with %PATH% to get things right, and both 
> > approaches
> > have their own set of problems.
>
> Everything on Windows is a nightmare here :)
>
> You would need to set up the %PATH% correctly if you used a specific
> version of GTK+ or not (from my experience). I am not suggesting we
> put the dlls in a common path and even then that's never enough
> (unless things drastically changed since I did it).

No need to fiddle with %PATH% when your executable lives right next
to libglib-2.0.dll, libgtk-2.0.dll etc. In other words, put your .exe
and .dll's in the bin directory. Have a look at how GIMP does things,
it's a fine example of how to package things for Windows in a sane way.

In short: resist going too far with the Windows (dll hell inducing) way
and use the directory hierarchy the binary packages and thus GTK+ 
bundle
have put in place. a) users don't care how it's done as long as it 
works
(see GIMP) and b) save countless hours of your time hunting problems.

> > In the Qt world and other toolkits, most people just bundle their
> > dependencies. That's the standard and the right thing to do on 
> > Windows.
> > Application developers are in charge of delivering a Gtk+ (and other
> > deps) version that works for their app.
>
> This does have it's advantages too and what I ended up doing also.
> But it does feel quite wasteful.

These days, I don't think it matters much having a couple of different
copies of GTK+ and it's dependencies on disk. As long as things work
reliably, users mostly don't care. However, I can understand developers
wanting their installer to be as small as possible (sometimes even
obsessively). That's a different problem altogether...

> There is quite a battle in Windows
> GTK+ app developers getting their software out of the door with this
> approach and indeed the one I was suggesting.

Let's look for a solution to that problem then?
What if you as a packager could simply write a text file (stored right
next to the program's source it your scm of choice) describing what
you need and want:
- dependencies
- shortcut in start menu
- maybe even file associations
- ...
hit a button and have a .zip and/or .msi produced automatically. The 
zip
would be the equivalent of the GTK+ bundle but crafted especially for
your project and the .msi a full fledged installer, giving your users
the choice of how they want to install your project on their machines.

There's a start to such a thing here:
https://github.com/dieterv/pygtk-installer/blob/master/bin/build_installer.py
and comparable things have been done elsewhere.

This technique separates packaging from building on purpose as these
are different tasks that can be done by different people on the same
project (for example, shoehorning .msi packaging into jhbuild looks
like the wrong tool for the job imho).

We could even take a look at how Python's distutils creates .exe
installers. Those are self extracting compressed files, with an UI
specific to Python. This option could probably even be used by people
wanting to build an installer but not having access to a Windows
box (as .msi inherently means using WiX), adding another option and
choice to the mix.

> > Third, and the most important. Windows has no package manager. You
> > should not delegate on users the responsibility of making sure that 
> > a
> > working copy of GTK is installed. This is annoying enough with Java.
> > A .zip bundle (and maybe some facilities to shove that into your app
> > installer) is the best approach for now IMHO.
>
> Actually, YES. :) The absence of a package manager (forgetting John's
> email for the moment) is regrettable but including a package inside
> your installer which installs GTK+ is not a bad idea and if that was
> provided AND apps could set their paths up appropriately, it's better
> than having to do the whole installer crap for GTK+ per project. It's
> just one more level of modularisation that helps app developers IMO.

Except that doing such bootstrapping (an installer embedding another
installer) is extremely hard to get right. And each packager is going
to have to test install/repair/upgrade...upgrade again/uninstall for
each of his programs he/she wants to distribute. For all scenarios,
including the embedded part already being there, it being another known
good version, it being another known broken version, it being a newer
version, etc and for each "supported" Windows version.

Sorry, I'll bundle my dependencies any day over that horror story ;)

mvg,
Dieter