Currently when compiling GoogleTest from source code, source file
gtest_main.cc from GoogleTest repository is not compiled into any
library as in GoogleTest repository, where it is compiled into
libgtest_main.a. Instead gtest_main.cc is added to source file list
GTEST_SRC, which is then added to the list of source files of every
single GoogleTest based test application.
To simplify this gtest_main.cc is added to the source file list of
target gtest now. Additionally GTEST_SRC is merged into
lib_gtest_SOURCES, since both variables defined source files for
GoogleTest libraries.
Now target gtest generates library libgtest.a, which already contains
the main function from source file gtest_main.cc. This is different to
GoogleTest build system, where both are separated into two independent
libraries libgtest.a and libgtest_main.a.
There are more, but these are most common ones.
There are also a number of urls that don't behave well when https, so those are skipped
At some point I have also started marking non-working URLs as [DEAD LINK], though
that's not a full coverage.
The end goal of this cleanup is to have all reports grouped in
subdirectories of the new 'reports' directory.
This first commit moves the standard reports
which mostly involves renaming several modules and targets.
On Windows boost::filesystem::path's string() produces a string
that goes out of scope with the function in which it's called, so
returning its c_str() ptr yields freed memory, usually full of garbage.
This has an interesting side effect in gnc-file.c's check_file_path():
Since the memory is freed, g_path_get_dirname() reuses it after an
iteration or two, writing its result into the same address. The
following strcmp naturally returns 0 because it's comparing two
instances of the same ptr, so check_file_path falsely reports that
the proposed save path is in GNC_USERDATA_DIR.
Add function to create an absolute file path from a prefix path and a
relative one. If the prefix is null, then the root directory of the
current path is used.
Revert using boost::locale to generate std::locales as boost::locale-
generated locales don't implement std::locale::facet and there was
a bug in the boost::locale ICU wrapper code that caused the wrong year
to be output for the last 3 days of December.
GCC's libstdc++ supports only the "C" locale on Windows and throws if
one attempts to create any other kind. For dates we work around this
by using wstrftime() to format according to locale and then convert
the UTF16 string to UTF8. wstrftime() interprets the time zone flags
%z, %Z, and %ZP differently so we process those first before calling
strftime. This will have the unfortunate effect of not localizing
timezone names but it's as close as we can get.
We can't use std::locale::global because all streams imbue it by
default and if it's not 'C' (aka std::locale::classic) then we
must imbue all the streams that we don't want localized, and that's
most of them.
Provides error checking for setting the C++ locale from the environment.
This is necessary both because the environment might have an invalid
locale, which would cause an unhandled exception crash.
On windows std::locale("") can't handle some Microsoft-style locale
strings (e.g. Spanish_Spain) so we use boost::locale's gen("") function
to set the locale--though even that can't handle a Microsoft-style
locale string with an appended charset (e.g. Spanish_Spain.1252) and
that's what glibc's setlocale(LC_ALL, NULL) emits.
Until now GNC_CONFIG_HOME was more or less hard-coded.
Now it can be set via environment variable GNC_CONFIG_HOME.
In addition it will automatically be created to avoid potential
user confusion.
When the preference dialogue is loaded and options are set, the ones
with registered callbacks fire causing parts of Gnucash to be updated.
This was observed with gnc_split_register_load being executed 5 times
for each open register when the preference dialogue was loaded.
To overcome this, a couple of functions have been created to block and
unblock all registered prefs and used while the preference dialogue is
loaded.
Always use absolute paths for configured directories (BINDIR etc.)
Abstract out the guts of gnc_gbr_find_foo_dir for foo in lib, bin, and data.
etc requires special handling because of the way it's treated if prefix
begins with /opt.
Always fall back on the configured directory if binreloc is disabled and
no default is passed in.
The swig 3.0 generated python wrappers trigger a warning converted into an error issued
by gcc 8.0 for using strncpy as follows:
strncpy(buff, "swig_ptr: ", 10);
The reason is this call will truncate the trailing null byte from the string.
This appears to have been fixed in swig master already but that's not released yet
so let disable the warning when compiling the swig wrappers until it is.
First, remove the unnecessary locale push & pop on <CT_TIME64>load.
Second, the registry accesses were caused by using g_win32_get_locale
to convert the Microsoft locale strings to POSIX ones. We don't care
what kind of string we get as long as we can pass it back to setlocale,
so remove that.
Third, gnc_push/pop_locale were used only in backend/dbi in a
very limited way and did much more than was necessary, so
convert them to C++ inlines in gnc-backend-dbi.hpp that does
only what we need them to.
The mingw-w64 toolchain bizarrely substitutes scm_to_locale_string()
for scm_to_utf8_string(). This results in latin1 (yeah, "locale" is
a lie) instead of utf8 which causes an assertion in
g_utf8_collate_key().
Perhaps equally bizarre, the compiler doesn't make the substitution
with scm_to_utf8_stringn(), so use that instead.
Replacing libgncmod-python, libgncmod-core-utils-python, and
libgncmod-app-utils-python with _sw_core_utils and _sw_app_utils.
The latter two are the modules that init.py wants to load and with
Python3 Swig appears to no longer make them available via libgncmod.
Note that there may still be some problems with actually using the
console, but it at least loads at startup without complaint.
In a previous commit I wrongly believed xgettext might not find
our strings if we used the fully namespaced boost::locale::translate or
aliased bl::translate instead of just translate. However that's
wrong, so I have changed the code to always use bl::translate.
At present these are
- log.conf
- config-user.scm (previously config.user-2.0)
Implement one-time migration of these files to the proper directory if they previously exist
Look for a log.conf file in gnc_userconfig_dir instead of gnc_userdata_dir
Note this commit also uses boost::locale::translate for the first time.
We may need to fine-tune our use, but in the current state strings marked
for translation using that function are already picked up for gnucash.pot.
Move the CSS settings file to a location based on XDG_CONFIG_HOME which
is OS dependant but with slight changes for Windows and OS X.
- Windows: CSIDL_APPDATA/Gnucash
- OS X: $HOME/Application Support/Gnucash
- Linux: $XDG_CONFIG_HOME/gnucash (or the default $HOME/.config/gnucash)
- 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.
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.
When building from git it will add targets to generate the swig files.
When building from tarball it will just point at the generated source
files from the tarball.
When building from git it will add targets to generate the swig files.
When building from tarball it will just point at the generated source
files from the tarball.
- the two dist_add_... macros now both take a list of file names
as argument so more files can be added at once to the dist tarball.
- dist_add_generated now creates the right target by itself. There's
no need to pass one any more
- make the swig generated *.py module files explicit output files
- change a couple of custom_targets into custom_commands. The only
reason they were defined as targets was to ensure they got built
before the dist tarball. This is now properly handled by the
dist_add_... macros.
- correctly handle dependency on swig-runtime.h (using OBJECT_DEPENDS
was not the way to do it according to that property's help page)
cmake with unix makefiles fails to resolve dist dependencies
added from COPY_FROM_BUILD if these dependencies aren't built yet.
This commit replaces the COPY_FROM_BUILD based logic with two new functions
'dist_add_configured' and 'dist_add_generated' to indicate which files should
be included in the dist tarball. The latter also adds a target level dependency
to the dist tarball custom command. Hence the former should
be used for files that get generated during a cmake run while the latter
should be used for files generated as the result of a 'make/ninja-build' run
(like files for which an add_custom_command rule exists).
Note: this commit also temporarily disables the dist target when building
from a tarball (and hence it won't be tested in distcheck either). This
will be handled in a future commit.
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.
The preference schema migration collects all schema mutations that can occur
when upgrading to a newer gnucash version. The old gconf to gsettings conversion is
integrated in this system as well. Newer schema mutations will happen based on version
number upgrades though.
The preference that got replaced is "use-theme-colors". Based on discussion in bug 746163
(https://bugzilla.gnome.org/show_bug.cgi?id=746163) and gnucash-docs PR#105
(https://github.com/Gnucash/gnucash-docs/pull/105) this has been replaced with
"use-gnucash-color-theme" with inverted meaning. The old option is kept around for one or
two major release cycles to allow seamless conversion.
Sets paths for finding componenents depending on the state of ENABLE_BINRELOC,
GNC_UNINSTALLED, GNC_BUILDDIR and whether any install paths have been set
outside of CMAKE_INSTALL_PREFIX.
GNUInstallDirs changes the name of CMAKE_INSTALL_LIBDIR depending on the
operating system and distro. When CMAKE_INSTALL_PREFIX is /usr,
/usr/local, or any subdirectory of /opt it also changes
CMAKE_INSTALL_FULL_SYSCONFDIR to /etc. An earlier commit by Aaron Laws
mirrors the name of CMAKE_INSTALL_LIBDIR to the build library directory.
It's possible for builders to set any of the install directories
anywhere they please.
Setting any directory outside of CMAKE_INSTALL_PREFIX breaks Binreloc so
the toplevel CMakeLists.txt now detects that and disables Binreloc.
If Binreloc is enabled then all path queries use it to find paths. This
works in the build directory because the gnucash executable and all of
the test programs are in build_directory/bin and LIBDIR, DATADIR, and
SYSCONFDIR can be found in the same root path.
If Binreloc is disabled then in order to build or run programs from the
build directory one must set GNC_UNINSTALLED and set GNC_BUILDDIR to the
absolute path of the build directory. When those are set GNC_BUILDDIR
replaces CMAKE_INSTALL_PREFIX in all paths that are subdirectories of
CMAKE_INSTALL_PREFIX; paths that are not in CMAKE_INSTALL_PREFIX are
appended whole to GNC_BUILDDIR. This process is constent between CMake
and gnc_path_get_foo. GnuCash is unlikely to run from a DESTDIR without
Binreloc.
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.
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.
- 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
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.
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).
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.
