Re: [GERRIT] gbuild migration: pyuno module

On 08.06.2012 09:49, Stephan Bergmann wrote:
> 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.
Thank you for this detailed explanation.
Done, pushed a new change set to gerrit: 
https://gerrit.libreoffice.org/#/c/179/
(Also i'm trying to follow a simple rule: do not migrate and refactor in 
one step, this one is really small to make an exception.)

> > 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?
building it now as bin/python_wrapper.exe and moving it with new 
CustomTarget_python_wrapper.mk target to
bin/pyuno/python.exe.

Regards
David