?

Log in

No account? Create an account

Gnucash

« previous entry | next entry »
Nov. 29th, 2006 | 01:09 am

I feel like I'm completely bonkers trying to rework gnucash to use mono on OS X.

I made some progress converting the automake/autoconf stuff to CMake, it still doesn't remotely compile, but at least its trying to compile the engine. (It's currently looking for config.h, which since I didn't use autoconf is obviously missing).

I know I have trouble finishing things, but I do really want gnucash back and I do want to be able to interact with it from a language other than scheme which does provide a bit of motivation. (Though instead of using mono, I wonder if it'd be easier to parse scheme code with python).

Link | Leave a comment | Share

Comments {6}

Derek

(no subject)

from: warlord_mit
date: Mar. 7th, 2007 08:43 pm (UTC)
Link

Install MacPorts.
Start the terminal
sudo port install gnucash
wait a while.

Read http://wiki.gnucash.org/wiki/MacOSXInstallation for more information

Reply | Thread

Diane Trout

(no subject)

from: alienghic
date: Mar. 7th, 2007 09:41 pm (UTC)
Link

Yeah I knew about that, there were some problems with g-wrap on an intel mac. The last time around of using mac os x, I tried using fink (which is what's currently recommended for intel os x) and I got fed up with how it wanted to suck in its own copy of python, x11, etc.

Given the heavyweight dependencies for fink installations, I might as well just run debian in a VM. So currently I'm just maintaining my own minimal set of dependences in /usr/local with stow.

Also X11 apps are a bit annoying under OS X, so I wanted to use gtk-quartz.

Do you know if anyones released a stand alone version of g-wrap that compiles properly on an intel mac?

Reply | Parent | Thread

Derek

(no subject)

from: warlord_mit
date: Mar. 8th, 2007 12:26 am (UTC)
Link

Standalone? No.

gtk-quartz would be nice, but it's not ready yet.. And last I heard it was still based on gtk1, not gtk2.

Also, gnucash 2.2 wont use g-wrap anymore! (YAY!)

Reply | Parent | Thread

Diane Trout

(no subject)

from: alienghic
date: Mar. 8th, 2007 05:38 am (UTC)
Link

Well I'll agree that gtk+-quartz is still under active development but this version is most definitely Gtk+ 2.0. I have gotten it to work with mono-gtk.

Also, gnucash 2.2 wont use g-wrap anymore! (YAY!)

Now that is good news, combine those two items and your half way to a X11-less version of gnucash on os x.

Though with respect to gnucash, all I really did was start porting from autotools to cmake.

Reply | Parent | Thread

Derek

(no subject)

from: warlord_mit
date: Mar. 8th, 2007 02:07 pm (UTC)
Link

w.r.t. gtk+-macox.... interesting. I wonder how complete that is, and how many of the dependencies it provides.

I'm not at all sure why you ported from autotools to cmake.. But honestly, if you want to get gnucash working with gtk+-macosx I can guarantee you that the gnucash developement team would be interested in your help and your patches would be gladly accepted.

Note, however, that porting to cmake doesn't count here. The auto tools work just fine. :-D

If you're interested in following up on this topic, I suggest you join the gnucash-devel@gnucash.org mailing list and bring up the topic there!

Thanks!

Reply | Parent | Thread

Diane Trout

(no subject)

from: alienghic
date: Mar. 8th, 2007 06:06 pm (UTC)
Link

gtk+-macox.... interesting. I wonder how complete that is, and how many of the dependencies it provides.

The build-gtk.sh script builds XML-Parser, atk, automake (1.7.9 and 1.9.6) cairo, docbook-files, expat, fontconfigure, freetype, gettext, glib, gnome-common, gnome-doc-utils-fake, gnome-icon-theme, gtk+, gtk-doc, hicolor-icon-theme, intltools, jpeg-6b, libIDL, libpng, libtool, pango, pkg-config, and tiff

Note, however, that porting to cmake doesn't count here. The auto tools work just fine. :-D

I might quibble with the "just fine" part of that. Autotools were a great idea, they demonstrated how auto-configuration is exceedingly useful in creating portable code. However it's my opinion that autotools has gotten old, creaky, and quite crufty, and now needs to die. (As a python programmer, I kind of wish that scons had won out, but CMake works, is reasonably fast, and has picked up some momentum.)

I believe CMake to be better because:
  • CMake 2.1 scripts work with CMake 2.4 (no &@#$ automake version incompatabilities)
  • CMake scripts can be read without knowing portable korn/bash shell and M4
  • The CMake configuration language is pretty easy to pick up.
  • CMake provides a standardized way of viewing and fixing incorrectly auto-detected variables
  • Not only does CMake work on unix like systems it also runs on windows, without cygwin
  • For IDE people CMake can generate KDevelope, XCode and Visual Studio files in addition to standard makefiles
  • CMake includes support for defining, building, and running tests

Though I do wish that CMake macros were real functions with real namespaces and not just a macro language. Also kitwares business model is, give away software, sell a book, so the documentation is a bit sparse. Though with KDE's adoption of CMake the free docs are getting much better.

Reply | Parent | Thread