CuteCash build errors -no rule to make target... iso-currencies-to-c.in

[John Ralls]

> On Apr 27, 2015, at 4:03 AM, Mark Murray <mamurray at optusnet.com.au> wrote:
> 
> On Wed, 2015-04-22 at 23:43 +0200, Geert Janssens wrote:
>> On Wednesday 22 April 2015 22:49:04 Christian Stimming wrote:
>> 
>>> Hi Mark,
>> 
>>> 
>> 
>>> thanks for the feedback about the cutecash build system. In fact,
>> this
>> 
>>> build error was introduced this January as the auto-generation of
>> 
>>> some files was changed on the Makefile.am side, but not on the cmake
>> 
>>> side. This isn't much of a big problem. I've just committed the fix
>> 
>>> and you should be able to build cutecash again. Have fun with this!
>> 
>>> 
>> 
>>> Contrary to what other voices here said, the "cutecash" experiment
>> is
>> 
>>> still able to compile and also run. To my surprise, it takes only
>> 
>>> very little effort to keep it up to date in terms of the build
>> 
>>> system. It still serves to show various things:
>> 
>>> 
>> 
>>> - The cmake build system could be used to build gnucash as well. For
>> 
>>> cutecash, it builds the first 20% of gnucash, but it could be
>> 
>>> extended to build all of gnucash just as well. Cmake has some
>> 
>>> advantages over automake such as it configures way faster; however,
>> 
>>> migrating the existing build system is a lot of work for little
>> 
>>> benefit, so we don't discuss this so far.
>> 
>>> 
>> 
>>> - Cutecash shows it is possible to run a C++ GUI toolkit on top of
>> the
>> 
>>> C code of the gnucash engine, using some of the glibmm/gtkmm
>> wrappers
>> 
>>> 
>> 
>>> - Cutecash shows that some new features such as Undo/Redo can be
>> 
>>> implemented rather easily once we get away from C
>> 
>>> 
>> 
>>> - Cutecash shows that another GUI on top of the gnucash engine is
>> 
>>> possible, so that some new features are available (Undo) while the
>> 
>>> minimal subset of existing features can be maintained. Of course,
>> 95%
>> 
>>> of the features in main gnucash cannot be found in a new GUI, as
>> each
>> 
>>> feature requires a lot of GUI code implementation, which nobody will
>> 
>>> want to do.
>> 
>>> 
>> 
>>> That's why I still keep the cutecash experiment in a state where it
>> 
>>> can be compiled and run. Except for the rare occasions when the
>> build
>> 
>>> system changes, which is what you ran into.
>> 
>>> 
>> 
>>> Regards,
>> 
>>> 
>> 
>>> Christian
>> 
>> 
>> 
>> Hi Christian,
>> 
>> 
>> 
>> I'm quite happy the Cutecash experiment is still functional and
>> showing these benefits. For me Qt is still a viable candidate to
>> eventually replace gtk as GUI toolkit. In that context Cutecash is an
>> invaluable source of experience and examples of how to do it.
>> 
>> 
>> 
>> So thanks for keeping it up to date.
>> 
>> 
>> 
>> Regards,
>> 
>> 
>> 
>> Geert
>> 
>> 
>> 
> Hi,
> 
> thanks for all the feedback.
> Success! I managed to build cuteCash. Hooray.
> 
> I'm not sure if or what I can contribute. But at least now I can do some
> more exploring.
> 
> There are a lot of discussions out there about desktop applications and
> tools we can use to build them;
> - GTK vs Qt; Qt seems to be winning
> - the future of GTK; many comments say it is going in the wrong
> direction
> - But, Cinnamon desktop is built using GTK, there may be hope
> - then there are all the HTML desktop items as well, such as Wt toolkit,
> NodeWebKit, Chromium Embedded Framework, TideSDK and XUL Runner and
> others.
> 
> So, there is plenty to keep me busy.

There are two impediments to switching toolkits: The use of GLib throughout the GnuCash and the mixing of functional code with GUI code. As Christian has shown with CuteCash, the former can be worked around, but the latter would require that the misplaced code be duplicated, which he wisely chose not to do.

Our strategy for the first is to rewrite the core of GnuCash in C++11, removing the GLib dependencies; for the second to extract all of the code that isn't Gtk calls into the core if it belongs there or into a "controllers" directory for things like format conversion. We'd appreciate help with either task.

Regards,
John Ralls