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.
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.
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
