Re: [Gtk-osx-users] Library dependencies of PyGTK on Mac OS X

On Dec 19, 2009, at 8:37 PM, John Pye wrote:

> Hi John
> John Ralls wrote:
>> There's already a python program, ige-mac-bundler, which is part of Gtk-OSX and takes care of packaging the files, including adjusting the installed names. There's a sample bundle file for bundling PyGtk Demo in the examples directory -- but not in the released version on sourceforge, so get it from git:// More information at
>> Do note, however, that different versions of OSX come with different versions of Python, and that can cause trouble when you distribute a Python-based bundle. I recommend building Python with jhbuild (set  _gtk_osx_use_jhbuild_python = True in your .jhbuildrc-custom) and including that Python in your bundle.
> I'd like to have a more careful look at ige-mac-bundler. I tried to work 
> through it but found the documentation a bit patchy. I tried to improve 
> it a bit -- perhaps you could take a look and maybe you are able to 
> address some of the FIXME comments I added there on the wiki.
> One problem I have is that my application is built using SCons, which is 
> not suported by jhbuild. That makes the nice streamlined dependency 
> tracking of jhbuild inaccessible to me (unless there's some nice 
> workaround hack?)
> Another issue is that there is not simple 'hello world' example for 
> ige-mac-bundler. Could there not be a simple (very short) hello-world 
> application included in the jhbuild modulesets that we could use as an 
> example of mac bundling? The 'giggle.bundle' example didn't seem to 
> reference something that exists in the default jhbuild repository.
> A final query -- are there any instructions for how to build the GTK 
> Framework? I know that you're not officially releasing this at the 
> moment, but I'd like to try out the bleeding edge version if possible. 
> Does it require a lot of manual hacking? I have a feeling that I'd be 
> more happy distributing our application as an installer that downloads 
> and installs a GTK framework in /Library, rather than including it with 
> our package. I'd also like our application to depend on a 
> system-installed version of Python, because we have reusable components 
> that I would ultimately also like to install in /Library rather than 
> hiding within our .app.

Giggle was an Imendio product that Richard wrote the annotated example file around. I've added gtk-demo and pygtk-demo examples to the git repo, as I told you above. There is gtk+-2.18.2/examples/helloworld, but it would bundle up exactly the same as gtk-demo does (exactly the same dependencies), so I don't see why it makes a difference. Again, the gtk-demo and pygtk-demo bundling examples are in the git repo, not the release tarball.

Your documentation efforts are a good start, thanks. I'll refine and correct them a bit when I have time.

I don't know what SCons is, but if it doesn't provide any dependency tracking it doesn't sound very useful for Gtk-based applications, which thrive on dependencies. I suggest building PyGtk with jhbuild and then using whatever toolchain you prefer for building the rest of your app. You can use any tool you like to identify dependencies and add them to your "MyApp.bundle" file.

The framework code is a bit of a mess, but you're welcome to whack on it. You'll find it at git:// It does include code to build an mpkg. The problem with it is that it's horribly out of date (Gtk+-2.14) and shorts out the dependency information in the modulesets, running a series of "buildone" commands, the sequence of which is hardcoded into the framework shell scripts (yes, shell, not Python.) I think it would make more sense to modify ige-mac-bundler to make the frameworks, and I've poked at it a little bit, but not written any code for it.

Because Gtk+ and all the associated stuff is Linux-oriented, it uses Linux versioning that does not fit well into the framework versioning scheme, so having your app depend on Gtk+ frameworks installed in /Library is perilous indeed: It's begging to bring MSWindows's "DLL Hell" to OSX. Not at all recommended. 

You can, I suppose, use the built-in python 2.5 (which is available in both Leopard and Snow Leopard) if you're OK with not supporting Tiger users for your app. Since you'll be using, you can test the OS and install appropriately.

John Ralls

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