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.
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.
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.
userdata_home is a different directory on each platform we support (default /home/janssege/.local/share on linux for example)
and gnc_userdata_home is normally userdata_home/GnuCash.
These directories may not always exist (yet) in all circumstances, so properly handle
all of these possible situations.
- Remove trailing semicolons. They're not needed in shell scripts
- Don't create default XDG_DATA_HOME (<HOME>/.local/share) the code
should work equally well if that directory doesn't exist and so
not creating it tests another part of the code
- have gnc_validate_directory throw as well in case of a missing directory
that it shouldn't create. This allows to remove 3 other throws
- slightly adjust the error message in case of missing directory
- never migrate when the final directory is a temporary (sub)directory
This reverts commit 48483b1e3d, reversing
changes made to 53fbc6f62f.
This merge was unintentionally pushed to master. This branch still
needed improvements.
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 the C side an SCM guile_options object is wrapped in a GNCOptionDB. This is
however a multi-to-one relationship. That is there can be several GNCOptionDBs
wrapping the same SCM guile_options object. This happens for example when
a report is open together with its Options dialog. Both manager their own
GNCOptionDB object while both wrap the same SCM guile_options.
The problem in this bug was caused by a callback function picking the wrong
GNCOptionDB based on the given SCM guile_options object. Which GNCOptionDB
got picked was completely dependent on how g_hash_table_foreach would cycle
through the stored dbs. It appears this is dependent on the in-memory order
of the hash table's values.
By being more selective of which GNCOptionDB we're looking for, this
could be circumvented. The GNCOptionDB we want is the one related to the open
report options dialog. This GNCOptionDB is different from the one managed by
the report tab in that it has callbacks set. So from now on we search for
a GNCOptionDB that wraps the give SCM guile_options and has one particular
callback set.
The utf8 conversion is only used in the Windows specific section so there's no
need to define an overloaded function on std::string in this case.
Also CMakeLists.txt doesn't require the MingW specific library name setting
for boost::filesystem. Just removing the hardcoded one allows the build to
pick the right name up from the Boost_LIBRARIES variable.
To get the after_failure line work, I had to move the inline
build script to a separate script (util/travis-script.sh)
The second script (util/travis-after-failure.sh) will output
LastTest.log for cmake based builds and all files named
test*.log for an autotools based build.
Note: this commit also comes with a delibarate test failure
to illustrate the Travis behaviour. It will be removed in the
next commit.
This will run the different builds in parallel (depending on
resource availability on Travis).
The advantages are
- faster test results
- easier to spot which build type has failed
- shorter test log per build type to parse
This latter file can be created by the administrator next to the environment
file in order to override parameters set in environment file.
The reason for this is the environment file is always overwritten
during installation, while environment.local is never touched by
the installers. So making the changes in there ensures they persist
acros gnucash updates.
- Linux: use whatever the xdg spec dictates
- Windows: use AppData(Roaming)
- OS X/Quarz: use NSApplicationSupportDirectory special directory, which
typically resolves to $HOME/Library/Application Support
If the preferred directory can't be used the code will fallback to
$HOME/.gnucash (the old location) if it exists. It won't create it
however. Instead if missing it will fall back to the platform's
temporary directory.
Code is added also to automatically migrate all data from the old
location to the new (only the first time).
This is done by reverting the following two commits which disabled
and hid the option on maint:
- Hide Account Substring option
(commit 197faeab3f)
- Reduce to compatibility shim
(commit 19fe7d8a56)
It depends on libgncmod-test-engine which needs c++ building/linking.
Without this change the next commit would produce the following linker error:
/usr/bin/ld: ../../../libgnucash/engine/test-core/.libs/libgncmod-test-engine.a(test-engine-stuff.o): undefined reference to symbol '__gxx_personality_v0@@CXXABI_1.3'
/usr/lib64/libstdc++.so.6: error adding symbols: DSO missing from command line
Making the test compila as C++ solves the issue.
For reference commit ff07762 and commit 5e7dd9 seem to be related and
have additional explanations.
Apparently that platform trips over a missing newline at the end of the generated POTFILES.in.in file.
Adding one allows cmake to complete configuration and appears to be fine on Fedora as well
(although it worked fine without the newline too).
Thanks go to Michael Jung <gnucash-devel@mailinglists.mjung.org> for reporting this and proposing the fix.
cmake:
- add test-app-utils
- rename test-link-module to test-link-module-app-utils
- add gtest-import-map
autotools:
- move gtest-import-map from TEST_PROGS to TESTS (autotools) so it shows up in the colored results list
While I myself asked for it to be retained a couple of years back
I now believe it really makes no sense to keep on carrying
a completely outdated rpm spec file around. This should not
be part of the source and properly up to date and maintained
rpm spec files can be found in each rpm based distro that ships
gnucash.
It is split into
- /libgnucash (for the non-gui bits)
- /gnucash (for the gui)
- /common (misc source files used by both)
- /bindings (currently only holds python bindings)
This is the first step in restructuring the code. It will need much
more fine tuning later on.
These are currently unmaintained, cutecash us based on the obsolete qt4
and gtkmm is only used by cutecash. Whenever someone wishes to revive
this experiment it can be recovered from git history and be brought
into a separate repository.
Geert Janssens