On Mon, 2011-08-22 at 22:35 +0200, Lionel Elie Mamane wrote:
if uno.py is being loaded (presumably from its place in
@libdir@/@OOOINSTALLDIRNAME@/basis-link/program), it means the python
load path already contains that. If the python load path does not
contain that directory, adding it from within uno.py does not help
because of chicken-and-egg problem of python finding uno.py in the
first place.
Unless we want to allow distributions to install uno.py in
%{python_sitearch}, but *not* the other things it needs, such as
pyuno.so; I'm not sure I get the rationale for wanting to do that.
Yeah, I (distros in general, I suppose) for the part-of-a-distro case
anyway, want to install uno.py and unohelper.py in site-packages and
have "import uno" just work out-of-the-box for stuff like bibus without
them (or their down stream packagers) caring where or what version of
LibreOffice etc are installed.
Easiest thing to do was to leave pyuno.so inside the /foo/libreoffice
tree to be in the right place for its $ORIGIN:$ORIGIN/foo/ rpath to find
the libs it links to and munge uno.py to tell it where that is, and
something similar for the URE_BOOTSTRAP whose purpose I forget at the
moment.
C.
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.