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


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

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.