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 > files. > > 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 dependencies. 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. Regards, Christian _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
