Compile test-core in C++
dartme18 at gmail.com
Wed Nov 26 15:55:15 EST 2014
On Sat, Nov 22, 2014 at 10:02 AM, Chenxiong Qi <qcxhome at gmail.com> wrote:
> I converted QofCollection_s to a C++ class named QofCollection placed
> in same header file src/libqof/qof/qofid.h,
I would advise against putting the class declaration into this file. It can
certainly be done by following Mr. Rall's suggestion of #ifdef __cplusplus,
but it seems cleaner to me to have a separate .hpp file for several reasons.
> and the original
> QofCollection_s is replaced with this new class. Module src/libqof/qof
> is compiled successfully, but failed to compile src/test-core due to C
> compiler is the one used to compile, and
> src/test-core/unittest-support.h includes qof.h, then *includes
> qofid.h*. This is why I considered to compile src/unit-core to solve
> the problem. After guidance in previous mails from both of you, I
> realizd that's not a good idea.
Right. The C tests (using the gtest framework) shouldn't see any C++.
Actually, the C tests shouldn't change at all (ideally) in response to your
work. It sounds like your understanding is correct.
> Then, by seeing KvpFrameImpl, I was thinking to keep QofCollection's C
> and C++ implementation existing at the same time. Because
> 1. reach the very first step of the goal to implement a C++ version of
> 2. new C++ class is just used in the scope of src/libqof/qof, whereas
> the original C version can still be used by the features outside of
> src/libqof/qof. In this case, my problem mentioned above disappears.
> 3. unit tests and all test works can be done within src/libqof/qof
> only. No any side-effects to outside.
> 4. When migrate to C++ compiler to build the whole GnuCash
> application, it's the time to make features outside of src/libqof/qof
> make use of QofCollection class.
Exactly. You're on the path to victory :-)
More information about the gnucash-devel