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.
gnc_start_of_week
* ICU has a mature C++ api, so prefer that one in our C++ code
* Use PERR instead of fprintf for consistent reporting
* Add the ICU specific linker flags to the test case
this function creates some business data. moved from test-invoice.scm
without the invoice-specific tests. verified all invoices/bills are
created correctly.
it returns a vector-list of the 8 invoices generated.
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.
Instead of random locations only occasionally related to the
corresponding source.
Includes renaming libgnucash/engine/test/test-extras.scm and
gnucash/report/report-system/test/test-extras.scm to avoid a
naming conflict.
this will modify a test which was calibrated to record purchase price
only. fix transaction creation to add prices for both purchase and
sales, and also fix test which was assuming no sale price was bring
recorded.
This is the general case for any transaction creation. Rewrite other
transaction creation routines to use it. All tests still work
unchanged, which confirms this function works well.
This will allow tests to create multisplit transactions, of an
arbitrary number of splits. If the list-of-split's values are not
balanced (i.e. total 0), the engine will create an Imbalance-CUR
split.
The motivation is to allow creation of complex multisplit
multicommodity transactions eg USD50 + GBP20 (USD25) = EUR66 (USD75)
as well as their prices GBP/USD = 25/20 and EUR/USD = 75/66.
* USD -50
* USD -25 = GBP -20
* USD +75 = EUR +66
This will be useful in creating tests for stock-based reports, whereby
stock sales need splits in STOCK/ASSET/INCOME accounts.
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.
It seems that std::locales created by boost::locale::generator are
not entirely compatible: If used to create a new locale with a facet
for boost::date_time one ends up with the C locale and the facet.
For the time being avoid the problem by using boost::locale to format
dates and times. std::chrono gets calendar functions in C++20 so we
can switch date-time backends once we can adopt it.
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.
This involves renaming 3 functions:
gnc_uri_get_protocol -> gnc_uri_get_scheme
gnc_uri_is_known_protocol -> gnc_uri_is_known_scheme
gnc_uri_is_file_protocol -> gnc_uri_is_file_scheme
The *_protocol variants are marked as deprecated.
Additionally a number of local variables have been renamed from
protocol to scheme to support this change.
- gnc_uri_get_components will now return NULL as protocol if the input is a normal
file system path instead of a uri (it used to return 'file')
- gnc_uri_get_protocol will now return NULL if the input is a normal
file system path instead of a uri (it used to return 'file')
- gnc_uri_is_file_protocol now returns FALSE if protocol is NULL (it used to return TRUE)
- gnc_uri_is_file_uri now returns FALSE if input is a normal file
system path instead of a uri (it used to return TRUE)
- a new function gnc_uri_targets_local_fs will return TRUE only if its input
is either a file uri or a normal file system path. This function is now mostly
used instead of gnc_uri_is_file_uri in the current code base
- a new function gnc_uri_is_uri is added to check whether its input
is a valid uri (has protocol, path and hostname for non-file uris)
The first fix for this bug handled structs tm with ambiguous times.
This one fixes the GncDate constructor when the time is ambiguous
because it's in the DST-change hour, using the same add 3 hours,
construct the LDT, and subtract the 3 hours from the result.
The string constructor handles only simple-offset HH:MM timezones and so
is immune to the bug.
And don't ask to save a not-dirty or empty book, fixing
Bug 794870 - If no book is opened, gnucash still asks if the user wants
to save changes when opening a file
The core issue was that the delete visitor was never called because its parameter
type (char *) didn't match the boost::variant type (const char *).
Fixing the visitor's parameter type also require a const_cast
back to char * because that's what g_free takes as argument.
The rest of this commit is merely fixing KvpValue instantiations that
tried to create a char* KvpValue from a stack based const string instead
of a heap allocated one. That would bomb out on calling the
delete visitor.
test_suite_gncInvoice sets up the test suite. It's not part of the test
runtime, so stack variables in it have gone out of scope by the time the
tests are actually run. Making invoiceData static makes it permanent so
it exists at runtime.
First, save isn't necessary if the book is dirty, so don't... but that
means that the book has to be marked dirty after a session swap. No more
laziness.
Second, regardless of the outcome of inner_main_add_price_quotes the
session must be destroyed to remove the lock.
A couple of cleanups in QofSessionImpl::save as well: Rewrote the
descriptive comment to reflect how it really works when the backend has
gotten disconnected and removed the superfluous qof_book_set_backend
with the backend that we'd *just gotten from the book*.
Change all instances of bugzilla.gnome.org to bugs.gnucash.org, reflecting
our migration to a self-hosted bug tracker.
Inform the Translation Project Coordinator at release that this affects
translatable strings and that all message catalogs have been updated.
First change is to ensure gncEntry rounding is consistent. Internally
calculated values in the entry are never rounded. Consumers of
gncEntry's calculated values can request them either rounded or not.
Next use a pragmatical approach for calculating values on invoices based on
the entry values: do the rounding such that we never
create an unbalanced transaction while posting
That means
- round each entry's net value before summing them in net total
- accumulate all tax totals on invoice level per tax account before rounding
and round before before summing them in a global tax total
Hopefully this will catch a few more rounding issues in this area.
A complete solution can only offered if we allow users to manually correct
tax entries. This requires changes to user interface and data format
so that's not going to happen in gnucash 3.x.
This commit contains another round of cleanups in the
timespec to time64 conversion. There were a number of
false assumptions that time64 = 0 would be a bad date
in the xml parser. This commit corrects enough of them to
eliminate the bug. Further cleanup is probably advised but
can be done at a later stage.
Also Bug 791825 - Accounting Period dates off by 1.
The DST start/end dates were reversed *and* the DST offset had the wrong
sign in Windows, resulting in the effective timezone always being one to
the west off (i.e. PDT was -9 and PST was -8).
GLib's scribbling of freed memory is enabled on Arch so attempting to
read the deleted members of inst and book crash instead of reaturning
invalid results. These weren't really useful tests anyway.
The first attempt to fix this, a17bc85a, doesn't work because the
boost::date_time constructor gets enough information in most cases to
generate a date, just not the one we expect. This change looks for '-' in
the fourth position and if it's there assumes iso-extended format, otherwise
it assumes delimiter-less ISO without the 'T', i.e. %Y%m%d%H%M%S.
This allows direct conversion between Scheme numbers and gnc_numeric
without the performance or accuracy penalties arising from using doubles
as an intermediary.
This commit introduces a new feature flag:
GNC_FEATURE_GUID_FLAT_BAYESIAN. It signifies that the bayes import map
data are stored flat and by guid. Any time bayes import map data are
accessed, they are converted if necessary.
Before, it was necessary to remove '/' from tokens so that they won't be
divided up within kvp. Now that kvp doesn't parse tokens, it's okay to
pass '/', and it's better not to translate user-provided tokens if at all
possible.
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.
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.
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.
cmake:
- add test-app-utils
- rename test-link-module to test-link-module-app-utils
- add gtest-import-map
autotools:
- move gtest-import-map from TEST_PROGS to TESTS (autotools) so it shows up in the colored results list
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.
