With the explicit prototypes not marked as static unit test builds on Debian
Buster (using buster-backports) fail with
error: testing::internal::ParamGenerator<TestCase*> gtest_InstantiationAutoClearTestAutoClearTest_EvalGenerator_() was declared extern and later static [-fpermissive]
According to the comment preceding the declaration the only intent of the
explicit prototype (in newer versions of googletest implicitly defined by the
GTEST macros) seems to be to silence a warning which would cause a build
failure on Ubuntu 18.04 when using -Werror.
Builds on Debian unstable seem to build just fine without this explicit
declaration, hence I consider it safe to just drop it. However, builds on
Ubuntu 18.04 then fail (see above).
Making the prototypes as static should make both build environments happy.
app-utils now is an ordinery shared library
A few bits worth mentioning:
1. it's not guile-free just yet, so instead of a gnc_module_load
your code may have to call scm_c_use_module("gnucash app-utils");
to expose the scm side of the app-utils api. This call has been
added to gnucash-bin.c for example
2. while lots of noise in this commit is to rename from gncmodule-app-utils
to gnc-app-utils, I'll point out the library has also been moved from
<libdir>/gnucash to <libdir>. This required changes in app-util's
CMakeLists.txt file for the install side and in the top level
CMakeLists.txt file for the build directory structure.
3. The C side link module test has been removed as linking an ordinary
shared library should be considered well tested by the compiler devs.
The scheme side module load test has been slightly tweaked to no longer
try to use gnc:module-load, but instead now checks whether the app-utils
api is properly exposed to scheme after loading it via use-modules.
4. Dropped a completely obsolete README file.
With that in place we no longer need to (gnc:module-load "gnucash/app-utils" 0)
the app-utils gncmodule. An ordinary (use-modules (gnucash app-utils)) suffices
1. Instead of creating a C wrapper around gettext to then wrap in
guile, use guile's builtin gettext support directly.
The code still defines the _ and N_ shorthands. However it doesn't
really warant a separate module just for these two shorthands.
Instead define them in core-utils. So all code wanting to use
_ or N_ in guile should now use the (gnucash core-utils) module.
The bulk of this commit is actually deleting the scm-gettext
target and using (gnucash core-utils) instead of (gnucash gettext).
2. As the definition of _ and N_ is removed from app-utils.scm,
the app-utils test for a functional N_ macro has been moved to a
new test file in the guile bindinds tests.
3. The (gnucash gettext) module has been deprecated. Use
(gnucash core-utils) from now on.
This commit tries to do the minimum necessary to move the guile bits from engine
to bindings/guile. As engine is a very central piece in the software, this unfortunately
still touches many other source files:
- A few helper objects have been squashed together:
* engine-helpers-guile.[ch] (of which the c part is extracted from engine-helpers.c)
* gncBusGuile.[ch]
* gnc-hooks-scm.[ch]
- The initialization function of gncmod-engine no longer initializes the scm bits.
Any scm code that wants to interact with the engine code now has to load
the (gnucash engine) scm module, or sometimes (gnucash business-core).
The bulk of changes in this commit actually is updating all the scm consumers to do so.
- scm-scm target has been removed. Instead (gnucash utilities) is part
of scm-engine. A few dependency graphs have been updated for this.
More refinements will be in followup commits.
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.
These files were installed fairly ad-hoc into the share/gnucash/scm directory making
it hard to get an idea of where each file comes from.
The files are now structured as follows:
- any scm file authored by gnucash should go in share/gnucash/scm/gnucash or below
- most scm modules will be directly in that directory
- each module that comes with support files will get a subdirectory named after the
module's base name. For example next to engine.scm there will be directory
named engine for all support files of the engine module
- scm files that are not modules, but are loaded by modules go into
<module-dir>. For example gnc-utils.scm loads gnc-menu-extensions.scm
so that file will be installed in gnc-utils/gnc-menu-extensions.scm
- the report system is our largest module and only part of the restructuring
is done at this point. It will be refined further in future commits.
The same restructuring is also done for the compiled files.
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.
If the original date is an end-of-month date, we take it as an
indicator they always want monthdelta dates to be end-of-months.
This works for monthly/quarterly/halfyearly/annual.
Addendum to commit 65bfeaf5de which was
deemed to be an incomplete fix.
Also I'd forgotten to activate a test in test-date-utilities. Enable it.
Instead of recursing the date, we calculate the next month using an
index-based multiplier, and apply modulo/remainder as appropriate to
determine the next month/year.
Then we attempt to create new mktime, and if the resulting mktime's
month is not as expected, reduce the mday by 1 until resulting month
is correct. This fixes monthly intervals for end-of-month days.
Test via monthly/quarterly deltas, and also includes leapyear
calculation.
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.
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.
Clearer syntax helped find flawed test - while set-tm:mday directly
accepts 1-31, set-tm:mon accepts 0-11 to represent 1-12, therefore
must minus 1. set-tm:year accepts 92 to represent 1992, therefore must
minus 1900.
