Fix handling of gschemas.compiled. It should only be called
at install time to regenerate gschemas.compiled based on all
available gschema files. In the installation directory that
can be more than just our own.
Note to force the compilation to run after all gschema files
themselves are installed, the gnome and gnome-utils gschemas
have been moved into a higher-level gschemas directory and
the install command is added there.
If you need to do that for your build pass the values in on the cmake
command line.
As for all of the noise about Boost's install name if APPLE, just fix it
with the install name tool. There are instructions at the boost module
in gnucash.modules.
- Don't attempt to create a subdirectory of a non-existing home directory (use tmpdir as base directory in that case)
- Make sure all tests run in an environment with GNC_BUILDDIR and GNC_UNINSTALLED set. Otherwise
the one-shot old .gnucash to new GNC_DATA_HOME migration may already have run at build time,
preventing us from informing the user a run time.
- Re-enable the userdata-dir with invalid home test (linux only).
It will no longer attempt to use /home/janssege/.gnucash. That was
requiring lots of extra conditions.
It will also default to a base directory (gnc_data_home) in the
build dir if it detects the code is run during building or testing.
That again allows to simplify it as there's no need for temp dir
juggling in case the build environment doesn't have a writable home dir.
With the current setup when a dark theme is used with existing register
colours the text is hard to read as the dark theme may of changed the
text colour to white so with these changes the text is always black
unless they choose not to use the built in colours.
This reverts commit 9d8def84f3.
Another oops. The version number in the desktop file is not the
gnucash version but the desktop file specification version.
There are more recent specification versions available, but
we should only bump it after having verified our desktop file
adheres to those higher versions. So revert for now.
The swig wrappers don't really depend on git (but rather on swig) and there can be
situations the builder wants to generate the wrappers also from a tar ball.
