[GERRIT] gbuild migration: pyuno module

[David Ostrovsky]

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 at 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