We had hardcoded HAVE_HTMLHELPW to always be true so the fallback
code that's only reached when it is false was never reached.
Time to drop this dead code.
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.
This starts by setting the gnucash version number in the 'project' call.
This will result in a number of variables set by cmake. The remainder
of this commit is to reuse the auto-generated
PROJECT_NAME, PROJECT_VERSION, PROJECT_VERSION_MAJOR
PROJECT_VERSION_MINOR, PROJECT_VERSION_PATCH and PROJECT_VERSION_TWEAK
instead of all the various instances of PACKAGE, GNUCASH_MAJOR_VERSION
and so on.
One parameter is worth mentioning - GETTEXT_PACKAGE
GnuCash is not using this directly (any more) but it has to be set before
including gi18n-lib.h.
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
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.
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.
