Hi Stephan,
moving out URE stuff of OOo windows installations indeed seems to be
more difficult than Unix (IMHO, as always :-). This seems to be more or
less rooted in the fact, that windows does not support (symbolic) links
on the on hand, while there is a mismatch between the binary world of
libraries, executables etc. and the registry. This simply is not thought
through well ... ;-)
Anyway, even using the mentioned registry entry does not seem to achieve
what you want to achieve, as this registry entry is globally unique and
does not belong to the office installation. So, what you actually want,
is an OOo installation specific entry, which points to the to be used URE.
AFAIK, the right place for a URE_BOOTSTRAP deployment variable is an OOo
installation specific registry entry, and, as you already suggested, to
introduce .ini files for all executables, so the latter may be avoided
by seamless integration/support of windows registry entries into the
deployment parameter approach.
Hope that helps
Kay
Stephan Bergmann wrote:
Hi all,
I am currently fiddling around with an OOo installation set from which
the URE has been extracted, see
<http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE>
for details.
On Unix/ELF, this already works reasonably well. I need a single
symbolic link from the base directory of the OOo-wo-URE installation to
the base directory of the URE installation. All the places where things
in OOo-wo-URE need to access things in URE are routed over this link:
- Executables and shared libraries in OOo-wo-URE find shared libraries
in URE they depend on via an RPATH (recorded in those executables and
shared libraries) that includes the link to the URE.
- The deployment variables URE_BIN_DIR (used in all other places in the
code where things in URE need to be accessed) and URE_BOOTSTRAP
(pointing at a fundamentalrc in OOo-wo-URE that contains essential
deployment variables to adapt the URE to the needs of OOo) are set in
the shell scripts soffice and unopkg (which should cover, via
indirections, most if not all of the executables that constitute the
"interface of OOo," see
<http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=19840>).
However, I have problems imagining how I can do something similar on
Windows:
- An installed URE already announces its location in the Windows
registry at HKEY_CLASSES_ROOT\Software\OpenOffice.org\URE. But, even if
all the code that needs to know this value can read it (e.g., we
introduce additional syntax so that the URE_BIN_DIR deployment variable
can be set to something like
"${registry:HKEY_CLASSES_ROOT/Software/OpenOffice.org/URE:Path}"), one
ugly problem would remain: It would not be easy at all to install two
different pairs of URE and OOo-wo-URE on the same machine (which is of
utmost importance at least for developers, and somewhat easily solved in
the Unix scenario above---all you have to do is adjust the one symbolic
link per installed URE/OOo-wo-URE pair).
- Assuming that OOo-wo-URE does know where the URE is located, how can
executables and DLLs in OOo-wo-URE access the DLLs in URE they depend
on? Extend the PATH? DLL hooks Hennes is currently working on (would
that scale)?
- Are there any clever places to set the URE_BOOTSTRAP deployment
variable so that all executables in the "interface of OOo" are
guaranteed to have it set (for themselves and any other processes they
spawn, i.e., ideally as an environment variable)? The last resort would
be to make sure that next to each such executable named foo there is a
foo.ini that contains a definition for URE_BOOTSTRAP.
Input more than welcome,
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
