Guile 3.0.5 fixed what they thought was a bug whering run-test returned
the rv of test-runner-on-final instead of the current test runner. Ctest
considered the returned object to be a successful test and always reported
the test passing.
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.
pass -DLEAKS=ON or -DODR=ON to enable these features. They have an
effect only with CMAKE_BUILD_TYPE=Asan and don't work on Apple because
Apple clang doesn't enable them.
This is done to be consistent with the GSettings
prefix (which is also a GLib subsystem).
In the process replace the magic string with
a single, globally defined macro.
They were only there due to how the source directories
are organized and not really adding useful detail.
Removing it from the resource paths gives more freeedom
wrt to the organization of source files.
This inverts the logic from
- having an xml file and extracting dependencies
from it to
- having a list of dependencies and generating
an xml file from it
In the original configuration adding or removing a
resource to/from the gresources.xml file would not
be detected by cmake as a change in dependencies.
The user would have to remember to rerun cmake manually.
By explicitly listing the dependencies, cmake will
properly recongifure and regenerate if that list is
updated. The remainder of the dependency configuration
also ensures proper rebuilds of gnucash, libaqbanking
and libofx if any of the resource files change, a new
one is added or an existing one is removed.
For reusability the code to generate the gresource related
files as been extracted into a separate function.
Found via `codespell -q 3 -S *.po,./po,*.min.js,./ChangeLog*,./NEWS,./borrowed,./doc/README*,./AUTHORS,./libgnucash/tax/us/txf-de*,./data/accounts -L ans,ba,cas,dragable,gae,iff,iif,mut,nd,numer,parm,parms,startd,stoll`
The new modules regime can only find files in the final modules
layout, so interdependent files can be built only if they're linked
first or have a strict dependency order provided to cmake. In many
cases the latter is impractical.
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.
Resolves most merge conflicts. The only bit I was unable
to merge from maint into master is the use of match-lambda
in category-barchart.scm. This will have to be redone manually.
Emit appropriate deprecation warnings in case code tries to invoke the removed functions.
Only for gnc:module-load a more elaborate compat function has
been written which should allow code using this obsolete function
to continue to function. The emitted deprecation warning will
guide the user to update his/her code for future compatibility.
That should trigger a regeneration of these swig sources if
any of the header files change.
This is done via a small macro that can be reused for other wrappers as well.
Note
cmake 3.15 introduces a 'FILTER' generator expression
that might allow us to do something like the following:
$<FILTER:$<TARGET_PROPERTY:baselib,SOURCES>,INCLUDE,"*.h[pp]?$">
I toyed briefly with that idea but it currently has two issues:
1. 3.15 is newer than our current minimum cmake requirement, so we can't
depend in that feature yet.
2. the sources are relative to *their* source directory, which
is different from the one in which the wrappers are generated
So they should still be properly transformed into absolute paths
Until now it was only done when building from git, but there's no
real reason not to do it as a normal build step in all cases.
It may have been unreliable in the past. There's no evidence
it still is.
This causes CMake to include their headers with -isystem instead of -I,
so the compiler doesn't generate warnings on them. ArchLinux was failing
to build because of such warnings.
Includes a function from cmake 3.6 to allow this to work on systems like
Ubuntu 14.04 that still provide only cmake 3.5.
Bill Sommerfeld
John Ralls
Geert Janssens
Richard Cohen
luz paz
Christopher Lam
c-holtermann