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

[Kean Johnston <kean johnston gmail com>]

> 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.
Why do you think this is unique to Windows? If you create a .rpm or .deb 
that depends on version x.y.z of some library, you have absolutely NO 
guarantees that during a system update (or some other package requiring a 
later version of that library) thatt the library isn't updated in some way 
that breaks you. In fact, due to conventions of using different namespaces 
for conflicting versions on Windows, that problem is rather neatly avoided.

> 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 :)
Just because you've had some difficulties with it doesn't mean its not an 
easily solved problem. Just because its been badly done in the past doesn't 
mean the concept of having a shared component is invalid, just that the 
implementation of it was. And as for things being in a state of "unknown", 
that's just absolutely untrue. If constructed properly, you can query the 
*exact* version of each library you depend on, using an OS-provided API, 
and store information about each exact version in one very easy to use, 
centrally managed location.

> 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.
I disagree, its a piss-poor and lazy way. it may WORK, but it is far from 
"fine" if things were done properly (which I am trying very hard to do). 
GTK absolutely *CAN* be created as a well-managed, stable, centrally 
available component. The authors of an individual application (like GIMP) 
may *choose* to bundle their own copies if they have some reason (or even 
just desire) to do so but it is NOT a shining example of how things should 
be done. If you believe it is then I fully expect to see you championing 
the install-with-application notion for GTK on Linux, because the problem 
domain is identical.

> 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
Sure, when there are only about 5 apps that use it that may be true. When 
you have a larger agenda, where you are trying to attract not only other 
open source projects but also commercial ones, that falls flat on its face 
I'm afraid.

> 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.
OMG NO! That's abhorent! Ask yourself this question: would you accept that 
behaviour on Linux? Every application that uses GTK bundling its own copy? 
That is .. *every single gnome application* bundling its own copy of GTK? 
Of course you wouldn't. Why are you then suggesting it for Windows?

Kean