build tools (was: XCode project)
christian at cstimming.de
Sun Feb 23 04:37:44 EST 2014
Am Donnerstag, 20. Februar 2014, 08:33:57 schrieb John Ralls:
> >>> As you may have noticed, I pushed an XCode project usable for
> >>> debugging GnuCash to GIT today. This is something I've used for
> >>> years, but it may or may not be useful to anyone else. I added some
> >>> notes to the HACKING file about how to use it.
> >> Thanks, Mike. I'll give it a try soon.
> >> I agree with Geert that it shouldn't go in top_srcdir unless it
> >> absolutely must, but I don't think contrib is the right place for it
> >> either. How about packaging/mac?
> > Moreover, whose job will it be to keep this project "current"?
> > Autoconf is (and should continue to be) canonical, which means someone
> > will need to update the xcode project when we add, remove, or move
> > files, dependencies, etc.
> Whoever's interested, I suppose, just as Christian maintains the CMake
> As for autotools, it obviously should remain the default build tool as long
> as we're tied to Gtk, but we'll want to review that when we get around to
> switching frameworks.
Just some additional clarification here: Whether to use autotools or not does
not depend on our gtk/glib dependency. You could build whole gnucash in its
current dependency state just as well by cmake.
It's only the large number of hand-written rules that occur every here and
there that would need to get converted. The current cmake build rules cover
approx. 20% of the additional hand-written rules (such as iso-4277-
currencies.c etc). As soon as we think cmake has more advantages over
autotools, we could switch this, indenpendently of our actual build
However, in the current state I don't see much advantages in cmake for us. In
my personal opinion I consider the CMakeLists code much more maintainable than
Makefile.am, and the build itself somewhat faster, but those are just nice
add-ons. The main context where cmake is much stronger is when the project
needs to be built by completely different compilers and also IDEs, such as gcc
and Microsoft Visual Studio. But as this is not on our agenda (and also
neither possible nor useful with the gtk dependency), I don't see any reason
to switch our build tools at this point in time.
More information about the gnucash-devel