Since Account.c is now Account.cpp, the function signatures look a bit
different internally. The tests rely on function signatures in error
messages. Instead of trying to figure out what the exact
function signature might be, I use a substring matching strategy to
ensure that the correct error was issued.
I.e., remove the shell invocation and with it the need to set the shebang.
Surprisingly this required some build-system modifications particularly
for cmake in order to correctly set the environment.
This effectively replaces the use of GNUCASH_BUILD_DATE with GNUCASH_SCM_REV_DATE.
The latter is extracted from the current commit if building from some kind of vcs
(currently only works correctly for svn and git). The info extracted while building
from vcs is then also added to the dist tarball so it's available when building
from tarball as well (via the file libgnucash/core-utils/gnc-vcs-info.h).
The same date is also used to set the date in gnucash' man page document.
A practical detail: I have changed the substitution variables in the man page template
from @- -@ to ${} so we could leverage CONFIGURE_FILE in cmake. The necessary
related adjustments have also been made to Makefile.am's substitution rules.
intltool-update should be run from the build directory, not the source directory.
If run from the source directory it will omit glade messages that have a context attribute
so all msgids with a msgctxt comment would be missing.
While it doesn't fully fix the python bindings, gnucash
now at least doesn't segfault on start up if built with
python bindings enabled. There are still issues to fix though.
On Windows CMake converts "\n" to CRLF, which causes xgettext to
mangle paths with [type: gettext/gsettings] in front of them and
also dirties the source directory with uncommittable changes.
The autotools build doesn't regenerate POTFILES.in and we've historically
maintained it by hand.
