On Aug 30, 2009, at 11:46 PM, John Pye wrote: Hi John If you could write bullet points for doing this, I'd be happy to expand it with screenshots etc. If you don't have a wiki, then maybe we could make a start here (on a new page linked from)... http://ascendwiki.cheme.cmu.edu/Porting_to_Mac
It sounds to me as though ige-mac-integration could perhaps be split
into two separate packages, if that is the case. Having to build a
package twice is highly irregular, and will fox most developers, I'd say.
I'd like to know why you think that way and fink/macports packaging. Is
there a reason why you'd rather they didin't? What's the philosophy
mismatch? I personally love being able to just type "apt-get install
whatever" and have all the dependencies installed automatically.
Do you have any details on how to build macports apps with Quartz
instead of X11?
There is no Gtk-OSX installer. There are some frameworks at the old
site (www.gtk-osx.org) which provide the very basic glib and gtk+
libraries and those upon which they depend. They aren't the current
version, and I haven't gotten the framework build scripts to work
enough to my satisfaction that I'm willing to provide prebuilt
binaries, so for now you have to build everything you need locally and
provide application bundles to your users. There is a module for
Glade, and I also maintain a large Glade-based application (Gnucash),
so I'm confident that it works just fine under Gtk-OSX.
If there are problems with the frameworks thing, then perhaps it could be useful to just provide a binary tarball of GTK+ (with a working
pkg-config script) as provided for GTK+ on Windows?
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).
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.
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.
IIRC, to build MacPorts with Quartz you just pass an argument like --enable-quartz to it at configure time.
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.
Regards, John Ralls
|
