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.
Addendum to 8b8c957ed -- if budgeted amounts exclude closing entries,
actual amounts should also exclude closing entries.
Amend documentation, modify budget test to add a closing entry which
will be ignored.
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.
with the function/declaration that they substituted.
Note that this doesn't use the recommended new GObject creation macros
because the class names in libgnucash/engine don't follow the gnome
naming convention.
* Ensure all the files included in report.scm are built before
any module calls '(use-modules (gnucash report))'
* Break circular dependency between report.scm and the files it loads via
'(load-from-path ...)'
For example file 'gnucash/report/html-linechart' is loaded via
'(load-from-path ...)' in 'reports.scm' it shouldn't call
'(use-modules (gnucash report))'. That would make it indirectly
depend on its own.
* In the same way 'engine-utilities.scm' was in a circular dependency loop
with 'engine.scm' though even more indirectly via (gnc-module-load ...)'.
The initialization code of libgncmod-engine calls
'(use-modules (gnucash engine))' which in turn tries to load-from-path
'engine-utilities.scm', completing the loop.
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.
With gncTaxTableGetDefault.
qof_book_get_default_tax_table would have been even better but it
would have created a circular dependency between QofBook and
GncTaxTable.
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
