g_assert() can be compiled out, so should not be used for tests
g_assert_true was removed
to fis https://bugs.gnucash.org/show_bug.cgi?id=792008 because
g_assert_true was introduced in glib-2.38 and at the time GnuCash required
only glib-2.26. GnuCash has required glib >= 2.40 since 8acbc41c6 so
g_assert_true can be restored.
If a function that returns an allocated pointer is passed directly into
something that does not take ownership of the pointer, the allocation is
leaked. This can be fixed by assigning the pointer to a new variable
and freeing it after operation on the memory.
The idea behind this is to not assume the project is always built
as "gnucash" exactly.
One example where it can be useful to use a different project name
would be when building multiple development versions of the project
on the same system and don't want these different versions share
the same settings in GSettings or the same stored passwords.
This starts by setting the gnucash version number in the 'project' call.
This will result in a number of variables set by cmake. The remainder
of this commit is to reuse the auto-generated
PROJECT_NAME, PROJECT_VERSION, PROJECT_VERSION_MAJOR
PROJECT_VERSION_MINOR, PROJECT_VERSION_PATCH and PROJECT_VERSION_TWEAK
instead of all the various instances of PACKAGE, GNUCASH_MAJOR_VERSION
and so on.
One parameter is worth mentioning - GETTEXT_PACKAGE
GnuCash is not using this directly (any more) but it has to be set before
including gi18n-lib.h.
This reverts commit 1a9fcfefad because
on MinGW cmake complains about the paths in pkgconfig files. This can
be addressed by using the MSYS2 cmake instead of the MINGW32 one, but
that requires some other changes... and there's also a path separator
bug in that version of FindPkgConfig.cmake.
This simplifies usage of GoogleTest, since independent handling of
GTEST_LIB and GTEST_INCLUDE_DIR is not necessary anymore.
Additionally CMake creates a dependency now between target gtest and all
test applications using it. This improves build process when building
GoogleTest from source code. When any test application is built,
GoogleTest library is automatically rebuilt if necessary now for
instance.
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.
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.
- 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.
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.
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.
- 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.
