On 09/23/2013 09:19 AM, Andrzej Hunt wrote:
I'm trying to get HSQLDB unit tests to run in a CppunitTest -- whilst
still in solver I added some paths locally to solver's unorc (which
worked fine, but not a great solution) -- now that we're running unit
tests in instdir I'd like some sort of permanent solution. (The reason I
want to use a CppUnitTest is that ideally we want to run exactly the
same tests on Firebird and HSQLDB, and since that also allows for
performance comparisons.)
HSQLDB's classpath is hardcoded in HDriver.cxx as:
vnd.sun.star.expand:$BRAND_BASE_DIR/" LIBO_SHARE_JAVA_FOLDER
"/hsqldb.jar"
As a first step I'd like to make this:
vnd.sun.star.expand:$LO_JAVA_DIR/hsqldb.jar
Either of these work when running LO normally, the latter is cleaner and
seems much more correct. (Patch is in gerrit, but outdated commit
comment now that we're in instdir --
https://gerrit.libreoffice.org/#/c/5953/ ).
The patch is just fine in itself anyway, so I pushed it now.
However neither of these work for unit tests: BRAND_BASE_DIR and
LO_JAVA_DIR are both set in fundamentalrc, which doesn't seem to be used
when running unit tests. It also looks like when running unit tests only
the ure/lib/unorc is used -- I'm not entirely sure how to procede here
-- using LO_JAVA_DIR within HSQLDB setting
LO_JAVA_DIR=${ORIGIN}/../../program/classes
works, but is that the desired way of doing things (adjusted by using
scp2 I guess to work on all systems)?
There are two things that tie all the bootstrap variables together:
The first is the uno{.ini,rc} file next to the cppuhelper dynamic
library, automatically read by the default, no-argument
cppu::defaultBootstrap_InitialComponentContext
(cppuhelper/source/defaultbootstrap.cxx) to bootstrap URE in any
application process. It sets those bootstrap variables necessary for
URE itself (and independent of any specific application like LO's
soffice). Historically, there are two instances of the cppuhelper
dynamic library, and consequently two instances of accompanying
uno{.ini,rc} (with different content): one in solver for the tools run
during the build---which in the past used to include cppunittester that
runs the CppunitTests---and one in instdir and installation sets---which
is now used also by cppunittester, which might be a change not
thought-through enough yet (see below).
The other is the URE_BOOTSTRAP bootstrap variable, normally set via
tools::extendApplicationEnvironment
(tools/source/misc/extendapplicationenvironment.cxx; called from
application start-up code like soffice_main,
desktop/source/app/sofficemain.cxx, and unopkg_main,
desktop/source/pkgchk/unopkg/unopkg_app.cxx) to point to the
fundamental{.ini,rc} next to the application's executable. The
program/fundamental{.ini,rc} in turn contains most bootstrap variables
you'll ever encounter (incl. LO_JAVA_DIR; for mostly historic reasons,
it offloads some variables to an additional uno{.ini,rc} next to itself
that can content-wise be considered an ini-file on of the above URE uno
ini-file).
The ideal with the recent move to instdir would of course be to run
CppunitTests against instdir (as the---premature?---move of
cppunittester to instdir manifests). However, one caveat I already
mentioned elsewhere "that comes to mind with running tests against
instdir instead of solver is that the [old] setup makes sure that any
JRE used by the tests is the one configured --with-jdk-home (by making
use of jvmfwk's 'direct mode'), not one found via the jvmfwk search
mechanisms. Another caveat is that should any of those tests
'accidentally' make use of bootstrap{rc,.ini}s UserInstallation, we
should override that to make sure those tests do not interfere with the
user's configuration."
Yet another caveat is that those CppunitTests can run against varyingly
"filled" instdirs, and thus behave subtly differently should they ever
start to pick up the various bootstrap variables defined across instdir
(which reference stuff in instdir that might or might not yet be there).
Therefore, it is a good thing that solenv/gbuild/CppunitTest.mk still
defines the relevant bootstrap variables manually. So, all that might
be necessary for you now is
diff --git a/solenv/gbuild/CppunitTest.mk b/solenv/gbuild/CppunitTest.mk
index 1f9390f..154841f 100644
--- a/solenv/gbuild/CppunitTest.mk
+++ b/solenv/gbuild/CppunitTest.mk
@@ -61,6 +61,7 @@ $(if $(URE),\
"-env:UNO_SERVICES=$(foreach item,$(UNO_SERVICES),$(call
gb_Helper_make_url,$(item)))") \
-env:URE_INTERNAL_LIB_DIR=$(call
gb_Helper_make_url,$(INSTROOT)/$(LIBO_URE_LIB_FOLDER)) \
-env:LO_LIB_DIR=$(call
gb_Helper_make_url,$(INSTROOT)/$(gb_PROGRAMDIRNAME)) \
+ -env:LO_JAVA_DIR=$(call
gb_Helper_make_url,$(INSTROOT)/$(LIBO_SHARE_JAVA_FOLDER)) \
--protector $(call gb_Library_get_target,unoexceptionprotector)
unoexceptionprotector \
--protector $(call gb_Library_get_target,unobootstrapprotector)
unobootstrapprotector \
) $(ARGS)
---let me know if that patch would make your test work.
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
