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.
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.
There were several issues:
- we store the compiled test*.go files in a tests subdirectory, but this is not
on the GUILE_LOAD_COMPILED_PATH. Added this directory to the path.
- guile was looking for 'script.scm.go' while we create 'script.go'. This is due
to how we invoke the scripts: guile -l path-to-script.scm -c (something)
we can replace this with -l path-to-script (without extension) as -l won't add
the extension. So I've rewrittin the test command to invoke (load-from-path).
- the test modules foo.scm, bar.scm and baz.scm should go in tests/gnucash
as they are defined as modules (gnucash foo), (gnucash bar) and (gnucash baz)
respectively.
- find html.scm/go on the load path instead of using a relative path.
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.
When building from git it will add targets to generate the swig files.
When building from tarball it will just point at the generated source
files from the tarball.
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.
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.
