NOTE: This does not have full coverage because the "if (!target || !ent)" body in the
collection_compare_cp function cannot be reached. There is too much safety in the rest of
the system to test this error.
NOTE: I made this a separate test from the test-engine so that I was able to check that it
by itself could test the full coverage of the qofid.cpp file. If it was part of the larger
test, I could have missed some parts that were covered incidentally elsewhere.
They were intended to test whether a gnc-module could be loaded
correctly. However several were not even properly implemented
and for the others the gnc-modules have been converted to
ordinary libraries. Testing whether a library can be linked to
is not a useful test. Link issues are triggered at build time
already.
Add CONFIGURATIONS keyword to unadorned tests, enables tests with
multi-config generators.
Add CONFIGURATION generator expression to libgtest.a and libgmock.a
build directory specs when building with Xcode so that it can
find them when building tests.
This commit tries to do the minimum necessary to move the guile bits from engine
to bindings/guile. As engine is a very central piece in the software, this unfortunately
still touches many other source files:
- A few helper objects have been squashed together:
* engine-helpers-guile.[ch] (of which the c part is extracted from engine-helpers.c)
* gncBusGuile.[ch]
* gnc-hooks-scm.[ch]
- The initialization function of gncmod-engine no longer initializes the scm bits.
Any scm code that wants to interact with the engine code now has to load
the (gnucash engine) scm module, or sometimes (gnucash business-core).
The bulk of changes in this commit actually is updating all the scm consumers to do so.
- scm-scm target has been removed. Instead (gnucash utilities) is part
of scm-engine. A few dependency graphs have been updated for this.
More refinements will be in followup commits.
This reverts commit 1a9fcfefad because
on MinGW cmake complains about the paths in pkgconfig files. This can
be addressed by using the MSYS2 cmake instead of the MINGW32 one, but
that requires some other changes... and there's also a path separator
bug in that version of FindPkgConfig.cmake.
This simplifies usage of GoogleTest, since independent handling of
GTEST_LIB and GTEST_INCLUDE_DIR is not necessary anymore.
Additionally CMake creates a dependency now between target gtest and all
test applications using it. This improves build process when building
GoogleTest from source code. When any test application is built,
GoogleTest library is automatically rebuilt if necessary now for
instance.
Currently when compiling GoogleTest from source code, source file
gtest_main.cc from GoogleTest repository is not compiled into any
library as in GoogleTest repository, where it is compiled into
libgtest_main.a. Instead gtest_main.cc is added to source file list
GTEST_SRC, which is then added to the list of source files of every
single GoogleTest based test application.
To simplify this gtest_main.cc is added to the source file list of
target gtest now. Additionally GTEST_SRC is merged into
lib_gtest_SOURCES, since both variables defined source files for
GoogleTest libraries.
Now target gtest generates library libgtest.a, which already contains
the main function from source file gtest_main.cc. This is different to
GoogleTest build system, where both are separated into two independent
libraries libgtest.a and libgtest_main.a.
gnc_start_of_week
* ICU has a mature C++ api, so prefer that one in our C++ code
* Use PERR instead of fprintf for consistent reporting
* Add the ICU specific linker flags to the test case
Instead of random locations only occasionally related to the
corresponding source.
Includes renaming libgnucash/engine/test/test-extras.scm and
gnucash/report/report-system/test/test-extras.scm to avoid a
naming conflict.
We can't use std::locale::global because all streams imbue it by
default and if it's not 'C' (aka std::locale::classic) then we
must imbue all the streams that we don't want localized, and that's
most of them.
Provides error checking for setting the C++ locale from the environment.
This is necessary both because the environment might have an invalid
locale, which would cause an unhandled exception crash.
On windows std::locale("") can't handle some Microsoft-style locale
strings (e.g. Spanish_Spain) so we use boost::locale's gen("") function
to set the locale--though even that can't handle a Microsoft-style
locale string with an appended charset (e.g. Spanish_Spain.1252) and
that's what glibc's setlocale(LC_ALL, NULL) emits.
Stefan Koch
John Ralls
Richard Cohen
Christopher Lam
Geert Janssens
Christian Gruber