On 08.06.2012 15:21, Stephan Bergmann wrote:
On 06/08/2012 09:49 AM, Stephan Bergmann wrote:
On 06/08/2012 09:22 AM, David Ostrovsky wrote:
2. on Linux I'm testing the clean build with --enable-python=internal,
and it seems not to work: opening Tools=>Macros=>Organize
Macros=>Python
and trying to open Hello World python Macor. I do not see any macros
available but see this warning in console
[david@wizball program (master)]$ ./soffice.bin --writer
'import site' failed; use -v for traceback
Any ideas how to proceed?
I can have a look.
Thank you very much for your help!
Attached pyuno.patch addresses three problems that I discovered:
* The sed call in pyuno/CustomTarget_python_shell.mk used wrong
variable names, so that expansions in the python wrapper script were
empty.
It was already done right. Later i changed the var names and added an
unique module prefix name, and forgot a couple of places...
** The pyuno/zipcore/python.sh also contains NOMACSECTION and
MACSECTION blocks, and the original pyuno/zipcore/makefile.mk made
sure to only include one of them. This still needs to be fixed.
Same story: fixed.
* SAL_DLLPUBLIC_EXPORT was missing from
pyuno/source/module/pyuno_dlopenwrapper.c, so that the pyuno.so
wrapper did not export initpyuno.
Well it was done intentionally, my understanding was that it is not needed.
* The program/python-core-2.6.1/ tree was missing from the
installation set. Getting this back was a bit tricky, as the old
system zipped together a temporary tree with some
python-core-2.6.1/lib/ structure, that ended up with that hierarchy
included in the zip, and scp2 specified to unzip it into the program
directory. I changed that to zip together the flat content of
$(OUTDIR)/lib/python, and instead explicitly create the
python-core-2.6.1/lib hierarchy in scp2 into which to then unzip the
zip file.
** Ideally, the "lib" directory could be removed from the hierarchy
completely, but that would require changes to all the places that set
up PYTHONPATH etc.
It seems to be an involved refactoring activity and should not be done
in one step with gbuild'ification. May be later.
** The original pyuno/zipcore/makefile.mk called strip on the files
that went into the zip. From the recent general discussion whether or
not to strip when building LO, it indeed seems acceptable to just drop
that.
Yes, i guess real Linux distros don't need it anyway: they build with
system python, or they build with internal python without debug
information: nothing to strip.
** We should also think about build dependencies, so that the zip file
gets recreated whenever its content would change.
Yes, it was my fault: it was lost during migration. Added it again.
Still can not see, why somebody would build pyuno, change internal
python files in python module and then would build pyuno again?! But
still we shouldn't break it.
Maybe it would be best to move creation of the zip file to the python
module?
Interestingly: the python-core for MACOSX is already built in python
module, so it should be definitelly moved also for Linux and Windows to
python-module ... but not in one step ;-)
Then, both executing ".../program/python -c 'import uno'" in the
installation set and running the Hello World macro from "Tools -
Macros..." worked fine for me o
Yes, it works now on Linux --with-python=internal and
--with-python=system (without clean build, only with
make pyuno.clean && make python.cean && make scp2.clean && make dev-install)
Still have to test it on Windows and ask somebody to test it in MacosX.
Thanks
David
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.