This might come as a surprise, but I've never actually looked at the
python bindings test suite, (src/optional/python-bindings/tests); my
colleague worked on it.
From what I'm looking at, it isn't useful and make check with
--enable-python-bindings should actually fail under many circumstances.
(My understanding is that there isn't currently a problem with make
check/distcheck when --enable-python-bindings isn't present; my thanks
go out to the folks who fixed that in April)
The gnucash libraries have to be findable when the gnucash_core_c.so
module is loaded. I use gnucash-evn to achieve this when running my
python programs that use the bindings.
The test suite does likewise, it invokes
$(top_builddir)/src/bin/gnucash-env via TESTS_ENVIRONMENT for the test.
This is wrong, unless make install has been called first (not required
for make check), executing (top_builddir)/src/bin/gnucash-env is
useless, it results in:
"""exec: 8: gnucash-env: not found"""
because that gnucash-env script is designed to execute the second stage
gnucash-env that is found in the installation, or anywhere else in PATH,
but not in the source/build directories.
So the current use of gnucash-env in python-bindings/tests/Makefile.am
is wrong.
Python also needs to be able to find the gnucash python modules when
they are imported. Python will look for modules in pre-defined
directories, and ones listed in PYTHONPATH.
The test suite sets PYTHONPATH via TESTS_ENVIRONMENT as well, and it
sets it to $(pythondir). This is again wrong, $(pythondir) is the place
where the modules go after installation. This means that make check can
only succeed if make install occurs first, or the gnucash modules have
already been installed somewhere else in the default PYTHONPATH, which
is again wrong.
The situation is complicated further by the fact that the .py and .so
files that are eventually installed together into $(pythondir)/$PACKAGE
($PACKAGE is gnucash) are still in separate places after make, the
python files are in src/optional/python-bindings, and the .so files end
up wherever the autotools put them, in my case
src/optiona/python-bindings/.libs/ .
So, I'd like advise from the list on how to proceed.
Here are some options:
1) make installcheck
Instead of performing the tests during make check, perform them during
make installcheck which will allow for the tests to be performed after
installation and to use the installed gnucash-env and install gnucash
module directory
See
http://sources.redhat.com/automake/automake.html#Install-Tests
I'm not sure which version of automake this requires and what version
GnuCash is requiring.
2) simpler tests
Figure out a way to construct an environment for the tests like
gnucash-env provides, only with the location of the libraries within the
source directory. Also, set PYTHONPATH to include both the location of
the .py and .so files.
With an environment like that, you could re-write the tests to not do:
python> from gnucash import Session
and to instead:
python> from gnucash_core import Session
3) same tests, better environment
Do the same with gnucash library search stuff as from 2) . Contract a
$PACKAGE (gnucash) directory that contains/link both the .py and .so
files. Set PYTHONPATH to include this directory.
With that option you could leave the tests alone -- they would still
"from gnucash import Session", which makes the test files more useful,
they can also double as documentation on how to use the bindings
post-install.
4) Give up
Remove the tests entirely and just ship python-bindings/example_scripts
for people to try out after installation.
So, your thoughts? 1, 2, 3, 4, or something I haven't thought of?
Mark Jenkins
Member
ParIT Worker Co-operative
cc Scott
cc fellow ParITistas
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
