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

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?


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