On Aug 31, 2009, at 5:43 PM, John Pye wrote:
Hi John Yes, ige-mac-integration needs to be restructured a bit, and pulling
the python bindings out is one approach. I could also create another
module called ige-mac-pygtk which rebuilds it with python support
after building python, which makes it invisible to the user (at least
to the user who doesn't peer too deeply into the innards).
The key thing is that the dependency system of jhbuild works correctly. So I don't see why you would want to hide the module from the user.
Fink and MacPorts are ugly hacks that attempt to recreate Linux inside
of OSX. They are rife with excessive and often conflicting package
interdependencies. I gave up on using either of them some years ago
after being unable to install Gnucash because of conflicting dependencies.
That would appear to be poor packaging practice, to me, rather than a fault of these package managers intrinsically, don't you think? Obviously there are some challenges to putting a package manager on top of an operating system that doesn't itself use one, but I think it can be managed. At least one should aim for a modular set of binaries that new developers can download in order to get started on a new machine. ...
It might be worthwhile for PyGtk to have a binary tarball. It wouldn't be for non-trivial C apps, because there isn't any way for a single
package like that to satisfy all of the various other dependencies, so
it makes more sense to just build everything at once.
There has *got* to be a better solution than requiring every GTK-OSX developer to build their whole GTK+ environment from source. I thought that better solution was fink (apt-get) or Macports. But if it's not (certainly, I was surprised at how poorly maintained the binaries for fink are), then perhaps just a big whopper tarball of GTK+ for both Python and C users isn't so bad...?
On Sep 1, 2009, at 6:28 AM, John Pye wrote: Hi John John Ralls wrote:
The wiki is at https://apps.sourceforge.net/trac/gtk-osx/wiki. You'll
need a sourceforge id to write to it.
I got PyGTK to build now, just using jhbuild. There was some playing around to make my SCons build use the correct version of Python such that PyGTK worked correctly, but that's resolved now. The steps for my particular approach are here: http://ascendwiki.cheme.cmu.edu/Porting_to_MacI'll get one of our other developers to cross-check and then fill it out a little more. If it looks complete and general, I can copy it over to your wiki. My next challenge is native Quartz theme. Is there a way to build 'gtk-theme-switch' using jhbuild, by any chance?
Gtk-OSX encourages a source build of the minimum installation for a
single app and bundling it for the exclusive use of that one app. Each
app contains its own dependencies, so there aren't any conflicts.
So I'll work on learning about 'bundles' and 'packages' for Mac OS X and see if I can manage to create an installer for my package. Our app a lot of non-GTK code for a calculation engine, together with a PyGTK as well as older Tcl/Tk GUI. Packaging for Mac could be difficult, because both GUIs use a shared 'model library' which should be accessible as files, somewhere, somehow.
It might be worthwhile for PyGtk to have a binary tarball. It wouldn't
be for non-trivial C apps, because there isn't any way for a single
package like that to satisfy all of the various other dependencies, so
it makes more sense to just build everything at once.
That would certainly be nice. Better still some kind of framework or whatever you call it on Mac.
Good that you've gotten PyGtk done.
Yes, it's possible for a system like Fink or MacPorts to work well, but it requires very good management of the packagers. The major Linux distros seem to get this to work better than Fink and MacPorts do. BTW, my experience with Fink and MacPorts is that neither provides much in the way of binaries. They mostly build in place. That may have changed for Fink, I haven't used it in a couple of years. I just did a MacPorts installation to check some patches I submitted to Gnucash, and it built everything. I don't see why you think that's preferable to jhbuild.
Consider also that when a jhbuild moduleset doesn't do what you want, there are several ways to adjust things so that it does. With Fink and MacPorts, you're stuck with what the packagers give you.
The "transparency" for the user in having two modules for ige-mac-integration (still with one source tree) is that one could just tell jhbuild to build meta-gtk-osx-python and be done with it, as opposed to the present arrangement where one has to build pygtk and then explicitly build ige-mac-integration with python turned on. Nothing would be hidden from anyone who cared to look, but the PITA factor would be much less.
GIMP has a copy of an older version of ige-mac-integration copied in, so if you actually care about it not working right you'll have to take that up with the GIMP developers.
There may be a better solution than build-it-yourself, and a distributable set of binaries for the most basic stuff might be it. I'm not so big a fan of Framework bundles for this purpose, because it's not feasible to integrate pkg-config with them and the source code has to be modified to use the #include magic, so you wind up with a -I for every one that you use, which results in seriously ugly gcc calls when you're building a Linux app that depends on them. Qt uses frameworks, wxWidgets doesn't. Some folks want frameworks for GTK+, so I persevere in trying to get them to build reliably.
There's a gtk-quartz-engine, and a couple of other theme engines already have modules (look at gtk-osx-themes.modules). The gtk-quartz-engine works OK, but it has some rough edges. You might also like to know that the Gtk+ devs have been working on a CSS theme engine and are leaning towards deprecating the existing ones in its favor.
Read the "Bundling" page in the Gtk-OSX wiki, and take a look at the forum, particularly http://sourceforge.net/apps/phpbb/gtk-osx/viewtopic.php?f=4&t=14 for much of what you need to know about bundling. Crak took an interesting approach to getting his bundle to load Python, and Python bundling is an issue that I need to work on some more.
Regards, John Ralls
|
