Re: Unit Test JVM Issues / URE_INTERNAL_JAVA_DIR

On 09/16/2013 11:27 AM, Michael Stahl wrote:
> On 15/09/13 23:02, Andrzej Hunt wrote:
> > On Sat, 2013-09-14 at 08:14 +0100, Andrzej Hunt wrote:
>
> > > stoc/source/javavm/javavm.cxx needs to find java which it does by
> > > expanding URE_INTERNAL_JAVA_DIR. This seems to be set within "unorc",
> > > which is found automatically by cppuhelper (cppuhelper/source/paths.cxx
> > > -- getUnoIniuri()) -- this loads unorc from wherever cppuhelper library
> > > is  found(called libuno_ccpuhlpergcc3.so -- not sure why this is the
> > > naming scheme?).
> > >
> > > Running LO from instdir: instdir/unxlngx6/ure/lib/unorc is used
> > > (generated by scp2/source/ooo/ure.scp) -- this contains the expected
> > > URE_INTERNAL_JAVA_DIR
> >
> > (It seems I was mistaken on this: the instdir unorc looks like it's
> > copied directly from ure/source/unorc , the scp one is/was used for
> > installation/)
>
> there is now some duplication there that needs to be cleaned up,
> probably by removing the scp2 definition of the rc files.

There is currently three uno{rc,.ini} files:

(1) cppuhelper/source/unorc is copied to solver and used by anthing that 
uses solver's cppuhelper library (built-time execution of various tools; 
CppunitTests).

(2) ure/source/uno{rc,.ini} is included in LO installation sets (and in 
instdir) as the URE uno{rc,.ini}, in the URE library directory.

(3) The LO-specific uno{rc,.ini}, sitting on top of the URE one, is 
defined via scp2 ProfileItems and included in LO installation sets (and 
in instdir) in the program directory.

[...]
> i'd say working on this right now is mostly a waste of time since i
> already am working on removing solver; hopefully with results this week.

One random caveat that comes to mind with running tests against instdir 
instead of solver is that the current 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.

(And at least for ELF with RPATH and for Mac OS X I would like to get 
away from the need for any [DY]LD_LIBRARY_PATH, when executing tools at 
build time and when running tests.  The key for that would be that /all/ 
executables and dynamic libraries, including build-time tools and 
CppunitTest dynamic libraries, are in well-known locations relative to 
each other, so that they can reference each other via @ORIGIN RPATHs 
(ELF) resp. @loader/executable_path paths (Mac OS X).)

Stephan