because gdk_rgba_to_string() returns a newly-allocated string
* get_negative_color is gchar* instead of const gchar*
* move to dialog-utils.c
* rename get_negative_color() to get_negative_color_str() in
window-main-summarybar.c
* add g_free to gnc_tree_model_account_dispose ()
* modify code to g_free () after use
Emit appropriate deprecation warnings in case code tries to invoke the removed functions.
Only for gnc:module-load a more elaborate compat function has
been written which should allow code using this obsolete function
to continue to function. The emitted deprecation warning will
guide the user to update his/her code for future compatibility.
This is now an ordinary shared library
* Remove test to load the gnc-module in scheme
* Rewrite test to load the module in C to actually test something.
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.
It already ensured it would initialize on first use.
It can as well register the hooks it needs for its
cleanup directly itself instead of depending on the
module loading system to do so.
It's primary purpose is to track gui objects' lifetimes. There's no
need for libgnucash (a non-gui library) to deal with that.
This required two book options related gui-only call backs
to be moved to gnome-utils as well.
With that in place we no longer need to (gnc:module-load "gnucash/html" 0)
the html gncmodule. An ordinary (use-modules (gnucash html)) suffices
html.scm is newly created. It serves two purposes:
1. expose the swigified html api to scheme
2. ensure gnc_html_initialize is run before first use (in scheme) of the api
With that in place we no longer need to (gnc:module-load "gnucash/report" 0)
the report gncmodule. An ordinary (use-modules (gnucash report)) suffices
Note: as gncmod-report did additional initialization, most reports
needed additional tweaks like using app-utils.
And in app-utils the initialization of the relative date terms
has been tweaked as well to run whenever the app-utils module
gets loaded first time, rather than having this initialized by
gncmod-report.
With that in place we no longer need to (gnc:module-load "gnucash/gnome-utils" 0)
the gnome-utils gncmodule. An ordinary (use-modules (gnucash gnome-utils)) suffices
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
The test passed but for the wrong reasons:
as no GNC_MODULE_PATH was passed to the test
it just didn't find the module. That's different
from finding a module with the same name but
a wrong sysver. This commit fixes that.
- move test modules into a subdirectory on Windows as well
- move the futuremod module into its own subdirectory
to avoid its load warnings each time gnc_module_init is called
That also tends to happen when building guile modules.
- remove the log handlers filtering out the futuremodsys warnings
They didn't match the actual warning signature anyway and
they're no longer emitted during testing
This is a first rudimentary separation of gnc-module tests
based on whether they require guile or not. Needs plenty of refinement
which will be applied in followup commits.
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 is just a cosmetic. This way the scm targets in the CMakeLists.txt
file are ordered according to their dependencies (targets later in the
file can depend on targets earlier in the file).
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.
That should trigger a regeneration of these swig sources if
any of the header files change.
This is done via a small macro that can be reused for other wrappers as well.
Note
cmake 3.15 introduces a 'FILTER' generator expression
that might allow us to do something like the following:
$<FILTER:$<TARGET_PROPERTY:baselib,SOURCES>,INCLUDE,"*.h[pp]?$">
I toyed briefly with that idea but it currently has two issues:
1. 3.15 is newer than our current minimum cmake requirement, so we can't
depend in that feature yet.
2. the sources are relative to *their* source directory, which
is different from the one in which the wrappers are generated
So they should still be properly transformed into absolute paths
By properly marking certain parameters as private or public
we can have cmake work out most of the link_libraries and
include_directoris for other targets dependent on core-utils
