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
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
