External App connection to a GnuCash file
esodan at gmail.com
Mon Sep 3 14:16:35 EDT 2007
2007/9/2, Christian Stimming <stimming at tuhh.de>:
> Am Mittwoch, 29. August 2007 21:52 schrieb Josh Sled:
> > "Daniel Espinosa" <esodan at gmail.com> writes:
> > > I found a macro in /macros/legacy_macros.m4 witch test for sscanf to
> > > support %lld (long long decimal integer) if so defines HAVE_SCANF_LLD.
> > > I think this is supported in recent gcc versions, then I can safetly
> > > define it in configure.in or remove this test in
> > > /lib/libqof/qof/qofutil.h.
> > I'm not 100% sure about the provenance of that code, but I'm pretty sure it
> > should not be removed.
> Josh is correct. The macro from legacy_macros.m4 turned out to be not legacy
> at all, but it is in fact needed a lot. To be more precise, the gcc/libc
> environment on Windows/mingw needs a different scanf() format character for
> LLD than what gcc needs on Linux. The test in legacy_macros.m4 checks exactly
> that. Hence, you need to copy the respective macro into your own application
> as well.
Thanks I've copied this macros in my project and it now compiles.
> On the other hand, the resulting format character itself is probably only
> needed inside the gnucash/gncqof implementation and doesn't have to be
> exposed to outside applications. Hence, in the long term this test probably
> should have to be done by your external application, and in gnucash this
> #ifdef check should be moved to an internal header file. Well, that's a
> long-term goal.
Scanf is used in file backend and other places inside GnuCash, then
this tests, I think, could be hide at the eyes of other applications
and just expose the usefull API for other applications.
Why is a long-term goal?
Is it represent too much work?
When will GC clean up this issues to make easy other applications to
use its data, may be to 2.4 or 3.0?
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los
More information about the gnucash-devel