Hi,
for pyuno, I would address the issue the same way you have addressed
it for the office, thus let python.bat/python.sh set the URE_BOOTSTRAP
variable.
That was my first thought, too.
But then I noticed that python.sh (and
the python symlink pointing to it) are only included #ifndef
SYSTEM_PYTHON (scp2/source/python/file_python.scp:1.18,
scp2/source/python/shortcut_python.scp:1.3), so that modifying python.sh
would not work in general. (However, I have no idea how any PyUNO
relevant stuff is found in the SYSTEM_PYTHON, anyway, which, I grok, is
found via PYTHONPATH=$sd_prog:... in our !SYSTEM_PYTHON python.sh.)
this must be solved by the distributors. I currently don't know how they
do this right now, probably by defining appropriate default values for
environment variables, maybe someone is listening here and can give us
some insight ?
The type-via-remote-bridge-suggestion is certainly a sensible
extension, but won't help here. When you have a component, that can
exist without the soffice process (will there ever be some :-) ... ?
), you would have to connect to an office just to serve as a type server.
Or you would have to make sure the (hypothetical, future) component
bootstraps into an OOo environment by other means (i.e., making sure
yourself that URE_BOOTSTRAP is set by putting a wrapper around that
component). I was mainly concerned with keeping existing scenarios
running.
As said before, I would stick to the python.[sh|bat] solution.
Bye,
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
