Re: Fwd: Plans for GTK+ Bundles for win32 and =?UTF-8?Q?win=36=34=3F?=
- From: dieterv <dieterv optionexplicit be>
- To: <gtk-devel-list gnome org>
- Subject: Re: Fwd: Plans for GTK+ Bundles for win32 and win64?
- Date: Thu, 08 Sep 2011 14:49:55 +0200
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
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 =
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,
some unknown installer out there is not going to break my stuff which
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
a patch I built with my developers hat on, before pestering people on
launch some script and presto, new installer for my program is built.
Having a shared "runtime" leads to extremely hard to debug situations
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.
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
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+
have put in place. a) users don't care how it's done as long as it
(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
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:
- shortcut in start menu
- maybe even file associations
hit a button and have a .zip and/or .msi produced automatically. The
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:
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
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 ;)
] [Thread Prev