This happens primarily on Travis. It looks like the shallow clone it makes is missing
tags. So if git describe fails, fall back to only the short commit hash (as we used to do
previously everywhere).
The main changes are
- group version and build information together
- increase size of application icon and name
- A more complete copyright notice (including 'Copyright' and 'GnuCash')
The default gtk provided about dialog widget won't allow for much more customization than that...
Note the build info has been condensed and is now based on 'git describe' which
returns a very concise, yet complete description of a commit starting from
the last tag that precedes it. This info will also be used anywhere else the build info
was displayed from now on, simplifying translations as well.
There seems to be more than one problem that causes the exception handler ("catch") to
get lost on Windows:
* Throwing from a constructor called from a member function of another object of the same
class. That's fixed here for the GncNumeric string constructor, but there's at least one other
instance I'm still working on in GncNumeric::to_decimal.
* Hidden memory allocation in a stack-allocated object like std::string, std::istringstream,
or boost::smatch: The throw causes the object to go out of scope which calls its destructor
and in that case the catch reference is either lost or never compiled in.
This change ifdefs out the creation of detailed exception messages on Windows to avoid
the destruction of the std::istringstream and its attached std::string, creates a series of
helper functions to ensure that the boost::smatch is in a non-throwing scope, and puts the
computed values directly into the member variables instead of delegating the construction
to a temporary and then copying out the values. The last item is more correct anyway, as
C++ constructor delegation is supposed to happen in the member initialization part rather
than the function body.
With these changes the exceptions from the GncNumeric string constructor are handled
correctly.
This will avoid a ninja-build from picking up a config.h generated by the autotools build
(in the root build directory). Picking up the wrong config.h may lead to all kinds of
subtle issues if the autotools run was done with different options than the cmake run.
The reconcile account dialog always displays a value of 0.00 as the
Ending Balance, regardless of account and statement date.
This is caused by function xaccAccountGetReconcilePostponeBalance
returning the wrong value, returning TRUE when it should return FALSE,
and setting balance to the default {0,1}.
The code uses bal.denom!=0 as an indicator that a valid balance was
received in variable v. However, bal is initialized to {0,1}
making the test always true even when we didn't receive a valid
value in variable v.
Thus, this function returns TRUE with *balance={0,1} when no valid
balance was found in "reconcile-info/postpone/balance".
This patch fixes the function to return FALSE if v doesn't hold
a valid value or if bal.denom is set to 0.
gtk-mac-bundler can't access the executable's rpath list so it can't
follow dependencies if they're not in $install_dir/lib from @rpath.
Autotools always sets absolute path install names so this should have no
adverse affects on other Mac builds.
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.
It was decided that this is not required as the user can choose the
required colours by setting the preference to not use the built in
register colours.
