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