The conversion assumed there were only three levels to bayes import
map kvp: IMAP token, user-supplied token, GUID/account name. In
actuality, since user-supplied tokens could have the delimiter in them,
there could be several. This fix takes that into account like so:
IMAP token, potentially several user-supplied tokens, GUID/account name.
The import map is undergoing two conversions at the same time: account names
to guids and an hierarchical representation to a flat representation in KVP.
The bayes data are stored in the KVP store. Before this commit, they are
stored under /import-map-bayes/<token>/<account guid>/count (where count
is the datum that "matters" in bayes matching).
The problem with this is that any token including the kvp delimiter
(currently '/') gets divided, and is not found correctly during bayes
kvp searching. The quickest solution to this is to replace all "/"
characters with some other character. That has been done, along with a
re-structuring of the bayes matching code to take advantage of c++
features to make the code more concise and readable.
Also modified some test functions to fix leaks and double-frees: the
same kvp value can't be in the kvp tree twice.
Also, when I added code to clean up after the tests, some things started
breaking due to double-delete. Apparently const_cast was hiding some
programming errors. Really? You don't say? When giving a GUID* to KvpValue,
the latter takes ownership of the former.
The nested representation was very noisy. Now, the string representation
shows one line per value with the full prefix which is also more
expressive than the old version.
The template avoids the need to cast to and from void*, and adds flexibility to
the targeted function's signature.
test-stuff.h defines a macro, "failure" which is used as an identifier
in the standard IO library, so I moved any inclusion of test-stuff.h to
the last include position so that "failure" wouldn't be defined before
the IO library was included.
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.
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.
I.e., remove the shell invocation and with it the need to set the shebang.
Surprisingly this required some build-system modifications particularly
for cmake in order to correctly set the environment.
There seems to be more than one problem that causes the exception handler ("catch") to
get lost on Windows:
* Throwing from a constructor called from a member function of another object of the same
class. That's fixed here for the GncNumeric string constructor, but there's at least one other
instance I'm still working on in GncNumeric::to_decimal.
* Hidden memory allocation in a stack-allocated object like std::string, std::istringstream,
or boost::smatch: The throw causes the object to go out of scope which calls its destructor
and in that case the catch reference is either lost or never compiled in.
This change ifdefs out the creation of detailed exception messages on Windows to avoid
the destruction of the std::istringstream and its attached std::string, creates a series of
helper functions to ensure that the boost::smatch is in a non-throwing scope, and puts the
computed values directly into the member variables instead of delegating the construction
to a temporary and then copying out the values. The last item is more correct anyway, as
C++ constructor delegation is supposed to happen in the member initialization part rather
than the function body.
With these changes the exceptions from the GncNumeric string constructor are handled
correctly.
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.
The reconcile account dialog always displays a value of 0.00 as the
Ending Balance, regardless of account and statement date.
This is caused by function xaccAccountGetReconcilePostponeBalance
returning the wrong value, returning TRUE when it should return FALSE,
and setting balance to the default {0,1}.
The code uses bal.denom!=0 as an indicator that a valid balance was
received in variable v. However, bal is initialized to {0,1}
making the test always true even when we didn't receive a valid
value in variable v.
Thus, this function returns TRUE with *balance={0,1} when no valid
balance was found in "reconcile-info/postpone/balance".
This patch fixes the function to return FALSE if v doesn't hold
a valid value or if bal.denom is set to 0.
gtk-mac-bundler can't access the executable's rpath list so it can't
follow dependencies if they're not in $install_dir/lib from @rpath.
Autotools always sets absolute path install names so this should have no
adverse affects on other Mac builds.
