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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
