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


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

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.