Re: HSQLDB / Unit tests
On Mon, 2013-09-23 at 15:22 +0200, Stephan Bergmann wrote: [... cut] 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. Yep, that works. I've uploaded the patch to gerrit to be safe ( https://gerrit.libreoffice.org/#/c/6023/ ) (no rush to have it in, so feel free to ignore it until after the conference). Also many thanks for the explanation! Cheers, Andrzej ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
HSQLDB / Unit tests
Hi all,
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/ ).
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)?
Cheers,
Andrzej
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: HSQLDB / Unit tests
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
Re: HSQLDB / Unit tests
On 23/09/13 15:22, Stephan Bergmann wrote: 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). the only reason why that (and a bunch of test libraries) is in instdir is the LibreOffice_Test installation set actually packages it. i don't know if anybody needs that. 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). how is that different from running against a partially filled solver? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: HSQLDB / Unit tests
On 09/23/2013 03:32 PM, Michael Stahl wrote: On 23/09/13 15:22, Stephan Bergmann wrote: 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). the only reason why that (and a bunch of test libraries) is in instdir is the LibreOffice_Test installation set actually packages it. i don't know if anybody needs that. I'd thought we'd come to the conclusion on IRC to remove LibreOffice_Test: Sep 19 11:34:23 pmladek mst__, sberg: I have created the LibreOffice_Test package for one QA guy. He does not longer work on LO. I am not sure if anyone else started to use it. So, I think that it can be killed. 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). how is that different from running against a partially filled solver? The start to pick up the various bootstrap variables defined [in ini-files] across instdir is the part that makes it different (as most of those ini filese were either not present at all in solver, or present in a form specifically suited for built-time use). Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
