Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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.