To use pass -DCMAKE_BUILD_TYPE=Debug or Asan -DCOVERAGE=ON and build as
usual, then do ninja lcov-initialize && ninja check && ninja
lcov-collect. The result will be a directory, <Builddir>/Coverage
containing lcov tracefiles, including an aggregate file gnucash.info
which you can use for further processing. It will also report an overall summary.
Note that only C/C++ files are included.
There's one more target, lcov-generate-html, that you can run after
lcov-collect. It will generate a simple website in
<Builddir>/Coverage-HTML showing coverage by source directory (the
directories in <Builddir> have coverage for generated files). Each
directory path is a clickable link to a page that shows coverage for
each source file; the filenames link to a page for each showing which
lines have been exercised.
- don't need to create/destroy GHashTable for each feature query
- plugs leak: g_hash_table_unref (features_used) not always called properly
- to check 1 feature, don't need to traverse whole GHashTable
If book has budgets, and GNC_FEATURE_BUDGET_UNREVERSED isn't set,
check and fix budget amount signs. Previously budgets were created
with assumption that sign reversal was set to credit amounts. A
heuristic approach is used:
- if budgeted expense is negative, conclude sign reversal is
"Income and Expense"
- if budgeted liability is positive, conclude sign reversal is
"None"
- otherwise conclude sign reversal is "Credit Accounts"
The above is calibrated to (hopefully) prefer sign reversal of Credit
Accounts.
This also drops the python wrapper for gnc-module. As for the guile wrappers,
python should use other means of loading our shared libraries.
This commit required a few tweaks to the dependency chain as some units
inherited dependency information from gnc-module's public dependency
interface.
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.
These files were installed fairly ad-hoc into the share/gnucash/scm directory making
it hard to get an idea of where each file comes from.
The files are now structured as follows:
- any scm file authored by gnucash should go in share/gnucash/scm/gnucash or below
- most scm modules will be directly in that directory
- each module that comes with support files will get a subdirectory named after the
module's base name. For example next to engine.scm there will be directory
named engine for all support files of the engine module
- scm files that are not modules, but are loaded by modules go into
<module-dir>. For example gnc-utils.scm loads gnc-menu-extensions.scm
so that file will be installed in gnc-utils/gnc-menu-extensions.scm
- the report system is our largest module and only part of the restructuring
is done at this point. It will be refined further in future commits.
The same restructuring is also done for the compiled files.
- add -Wno-deprecated-declarations to CXX_FLAGS as well. This was
reported by vorlonofportland in PR#401 to become necessary for glib 2.58
as that has deprecated g_type_class_add_private which appears in our
c++ code.
- change -Wno-deprecated-register into -Wregister. The former appeared to
be a clang dialect and alias for the latter (see
https://github.com/Barro/compiler-warnings for an overview of clang
and gcc warnings). It was moved to global CXX_FLAGS as it can only be
added for g++.
When building from git it will add targets to generate the swig files.
When building from tarball it will just point at the generated source
files from the tarball.
Several were only there because they used to be generated via autogen.sh
and hence had to be included because autogen.sh was not supposed to be run
in a tarball based build.
A few others aren't clear so I have left them in for now:
- gnucash.1 (man page)
- gnucash-design.info (because it's unclear what we want to do with that one)
These files should clearly be in the tarball:
- gnucash.pot -> for our translators
- ChangeLog -> can't be generated outside of a git repo
- gnc-vcs-info.h -> can't be generated outside of a git repo
- guile/python bindings -> to avoid a swig dependency when building from tarball
- the two dist_add_... macros now both take a list of file names
as argument so more files can be added at once to the dist tarball.
- dist_add_generated now creates the right target by itself. There's
no need to pass one any more
- make the swig generated *.py module files explicit output files
- change a couple of custom_targets into custom_commands. The only
reason they were defined as targets was to ensure they got built
before the dist tarball. This is now properly handled by the
dist_add_... macros.
- correctly handle dependency on swig-runtime.h (using OBJECT_DEPENDS
was not the way to do it according to that property's help page)
cmake with unix makefiles fails to resolve dist dependencies
added from COPY_FROM_BUILD if these dependencies aren't built yet.
This commit replaces the COPY_FROM_BUILD based logic with two new functions
'dist_add_configured' and 'dist_add_generated' to indicate which files should
be included in the dist tarball. The latter also adds a target level dependency
to the dist tarball custom command. Hence the former should
be used for files that get generated during a cmake run while the latter
should be used for files generated as the result of a 'make/ninja-build' run
(like files for which an add_custom_command rule exists).
Note: this commit also temporarily disables the dist target when building
from a tarball (and hence it won't be tested in distcheck either). This
will be handled in a future commit.
