Re: [GERRIT] gbuild migration: pyuno module

On 06/08/2012 09:22 AM, David Ostrovsky wrote:
> with the last change set https://gerrit.libreoffice.org/#/c/179/
> clean build on linux x86_64 with --enable-python=internal is working.

Great to hear.

> 1. What do you mean by this TODO comment in
> scp2/source/ooo/common_brand.scp
> [...]
> //TODO: This actually belongs into a module of its own:
> #if !defined DISABLE_PYUNO && !defined SYSTEM_PYTHON
> [...]

This needs to be placed into a bit of historic perspective.  For one, 
the various (optional) parts of a LO installation set are grouped into 
modules at the level of scp2 (and, depending on the format of 
installation set, you can select a subset of modules for installation; 
this works e.g. with Windows msi format and with Linux deb or rpm 
format, but not with Mac OS X dmg format, where you always have to 
install a complete LO).

For another, the infamous three-layer stuff once separated 
branding-specific files into modules of their own, away from the 
branding-agnostic rest (that then could be reused across various branded 
variants of the original OpenOffice.org, like we had back at Sun with 
StarOffice, BrOffice, etc.).  All the client-facing executables 
(soffice, unopkg, and also that python executable) were ending up in 
branding-specific modules.

The dilemma now was that the original separation of files into modules 
along the dimension of features (e.g., a separate module for PyUNO, see 
scp2/soruce/python/module_python.scp) would have had to be doubled when 
introducing the new dimension of branding-specific vs. 
branding-agnostic.  This lead to an increase in the overall number of 
packages, and in some cases, like that little python executable that 
would end up in a module of its own (feature: PyUno, three-layer: 
branding-specific), stuff was simply kept in a bigger module instead of 
properly splitting it out.

Now that three-layer is faint history, the best thing would be to clean 
this remnant up, moving the gid_Brand_File_Bin_Python entity from 
gid_Module_Root_Brand to gid_Module_Optional_Pyuno.  If you like, you 
can try getting into that scp2 stuff yourself.  Let me know if you need 
any help there.

> The thing is
> on unix:
> python.sh is get copied to bin/pyuno/python in Package_python_shell.mk
>
> on wnt:
> native python executable wrapper is built in pyuno/Executable_python.mk
> now and is delivered by default to bin/python.exe.
> But then we have a collision with native python executable artifact
> which get build in python module.
> How can i force on gbuild land (RepositoryFixes.mk doesn't handle
> executables, only libs so far)
> to create a python.exe not into /bin, but to bin/pyuno/python.exe
> (Windows isn't tested at all, though)

Good question.  Hopefully one of the gbuild wizards can step in?

> 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.  But what source do I need exactly for this?  Is it 
still a feature branch?  And <https://gerrit.libreoffice.org/#/c/179/> 
from above only gives me a "Not Found."

Stephan