Test repository to check push and ssh key
0ca248b0d5
all these bells and whistles seems to be hamburg specific. modules_type in you build seems to always be 'mod', so no need to track it. the whole source_config things is not use in our build either. note: this is a rough cut... there is probably left-over to trim as a consequence of this. |
||
|---|---|---|
| accessibility | ||
| afms | ||
| animations | ||
| apache-commons | ||
| apple_remote | ||
| autodoc | ||
| automation | ||
| avmedia | ||
| basctl | ||
| basebmp | ||
| basegfx | ||
| basic | ||
| bean | ||
| beanshell | ||
| berkeleydb | ||
| bin | ||
| binaryurp | ||
| boost | ||
| bridges | ||
| cairo | ||
| canvas | ||
| chart2 | ||
| cli_ure | ||
| codemaker | ||
| comphelper | ||
| configmgr | ||
| connectivity | ||
| cosv | ||
| cppcanvas | ||
| cppu | ||
| cppuhelper | ||
| cppunit | ||
| cpputools | ||
| crashrep | ||
| ct2n | ||
| cui | ||
| curl | ||
| dbaccess | ||
| default_images | ||
| desktop | ||
| distro-configs | ||
| dmake | ||
| drawinglayer | ||
| dtrans | ||
| editeng | ||
| embeddedobj | ||
| embedserv | ||
| epm | ||
| eventattacher | ||
| expat | ||
| extensions | ||
| external | ||
| extras | ||
| fileaccess | ||
| filter | ||
| forms | ||
| formula | ||
| fpicker | ||
| framework | ||
| gdk-pixbuf | ||
| gettext | ||
| git-hooks | ||
| glib | ||
| graphite | ||
| guw | ||
| hsqldb | ||
| hunspell | ||
| hwpfilter | ||
| hyphen | ||
| i18npool | ||
| i18nutil | ||
| icc | ||
| icu | ||
| idl | ||
| idlc | ||
| instsetoo_native | ||
| io | ||
| javaunohelper | ||
| jfreereport | ||
| jpeg | ||
| jurt | ||
| jvmaccess | ||
| jvmfwk | ||
| l10ntools | ||
| languagetool | ||
| libcroco | ||
| libgsf | ||
| libpng | ||
| librsvg | ||
| libtextcat | ||
| libvisio | ||
| libwpd | ||
| libwpg | ||
| libwps | ||
| libxml2 | ||
| libxmlsec | ||
| libxslt | ||
| lingucomponent | ||
| linguistic | ||
| lotuswordpro | ||
| lpsolve | ||
| lucene | ||
| m4/mac | ||
| MathMLDTD | ||
| mdds | ||
| Mesa | ||
| migrationanalysis | ||
| more_fonts | ||
| moz | ||
| mysqlc | ||
| mysqlcppconn | ||
| mythes | ||
| neon | ||
| nlpsolver | ||
| np_sdk | ||
| nss | ||
| o3tl | ||
| odk | ||
| offapi | ||
| officecfg | ||
| ooo_custom_images | ||
| oovbaapi | ||
| oox | ||
| openssl | ||
| package | ||
| packimages | ||
| padmin | ||
| pango | ||
| postprocess | ||
| psprint_config | ||
| python | ||
| pyuno | ||
| qadevOOo | ||
| rdbmaker | ||
| readlicense_oo | ||
| redland | ||
| regexp | ||
| registry | ||
| remotebridges | ||
| reportbuilder | ||
| reportdesign | ||
| rhino | ||
| ridljar | ||
| rsc | ||
| sal | ||
| salhelper | ||
| sane | ||
| sax | ||
| saxon | ||
| sc | ||
| scaddins | ||
| sccomp | ||
| scp2 | ||
| scripting | ||
| sd | ||
| sdext | ||
| setup_native | ||
| sfx2 | ||
| shell | ||
| slideshow | ||
| smoketestdoc | ||
| smoketestoo_native | ||
| solenv | ||
| soltools | ||
| sot | ||
| splitbuild | ||
| starmath | ||
| stax | ||
| stlport | ||
| stoc | ||
| store | ||
| svl | ||
| svtools | ||
| svx | ||
| sw | ||
| swext | ||
| sysui | ||
| tail_build | ||
| test | ||
| testautomation | ||
| testgraphical | ||
| testtools | ||
| tomcat | ||
| toolkit | ||
| tools | ||
| translate_toolkit | ||
| twain | ||
| ucb | ||
| ucbhelper | ||
| udkapi | ||
| udm | ||
| unixODBC | ||
| UnoControls | ||
| unodevtools | ||
| unoil | ||
| unotools | ||
| unoxml | ||
| ure | ||
| uui | ||
| vbahelper | ||
| vcl | ||
| vigra | ||
| wizards | ||
| writerfilter | ||
| writerperfect | ||
| x11_extensions | ||
| xmerge | ||
| xml2cmp | ||
| xmlhelp | ||
| xmloff | ||
| xmlreader | ||
| xmlscript | ||
| xmlsecurity | ||
| xpdf | ||
| xsltml | ||
| zlib | ||
| .gitattributes | ||
| .gitignore | ||
| acinclude.m4 | ||
| autogen.sh | ||
| bootstrap.1 | ||
| config.guess | ||
| config.sub | ||
| configure.in | ||
| COPYING | ||
| COPYING.LGPL | ||
| COPYING.MPL | ||
| download | ||
| g | ||
| GNUmakefile.mk | ||
| install-sh | ||
| Makefile.in | ||
| Module_tail_build.mk | ||
| ooo.lst.in | ||
| oowintool | ||
| post_download.in | ||
| README.cross | ||
| Repository.mk | ||
| RepositoryExternal.mk | ||
| RepositoryFixes.mk | ||
| RepositoryModule_ooo.mk | ||
| set_soenv.in | ||
| TEMPLATE.SOURCECODE.HEADER | ||
| unusedcode.easy | ||
Cross-compiling LibreOffice =========================== Notes on cross-compiling LibreOffice, written by Tor Lillqvist <tlillqvist@novell.com> <tml@iki.fi> in May, 2011. Cross-compilation of LibreOffice is not possible yet. Some initial work is done, "baby steps", but a lot remains. This work is highly experimental and done mostly in my own spare time just for the hacking pleasure. No promise, explicit or implied, is given that it will ever be finished. Searching for information about cross-compilation of OpenOffice.org (the predecessor of LibreOffice) you will find information about what actually was not cross-compilation, but using QEMU. My cross-compilation experimentation is going on for four platforms: Windows, iOS, Android and PowerPC Mac OS X. I work on the master branch of LibreOffice. Some other people have talked about setting up a separate branch for Android work, or even separate clones at github. I am not interested in that. General ------- In GNU Autoconf terminology, "build" is the platform on which you are running a build on some software and "host" is the platform on which the software you are building will run. Only in the specific case of building compilers and other programming tools is the term "target" used to indicate the platform for which the tools your are building will produce code. As LibreOffice is not a compiler, the "target" term should not be used in the context of cross-compilation. (For a case where all three of "build", "host" and "target" are different: consider a gcc cross-compiler running on Windows, producing code for Android, where the cross-compiler itself was built on Linux. (This is a real case.) An interesting tidbit is that such configurations are called "Canadian Cross".) Even though the LibreOffice build mechanism is highly unorthodox, the configure script takes the normal --build and --host options like any GNU Autoconf -based configure script. To cross-compile, you basically need just to specify a suitable --host option and things should work out nicely. In practise, some more details might be needed. See examples below. What is so hard, then? ---------------------- Despite the fact that the configure script takes normal --build and --host options, that is just the beginning. In practise a lot of work was necessary to separate tests for "host" and "build" platforms in the configure script. See the git log for details. And the reasonably "standard" configure.in is just the top level; when we get down to the actual makefilery used to build the bits of LibreOffice, it gets much worse. Windows ------- There is some support in LibreOffice already (from OpenOffice.org) for building it locally on Windows but with the GNU tool-chain, i.e. what is commonly known as MinGW. But as far as I know, that work has never attempted cross-compilation. This OOo-originated MinGW support attempts to support both running Cygwin gcc in its -mno-cygwin mode, and a native MinGW compiler. The -mno-cygwin mechanism in the Cygwin gcc is rapidly being obsoleted, if it isn't already, and I have not attempted to check that it keeps working. Ditto for native MinGW; if one compiles natively on Windows, why not use Microsoft's compiler, as OOo/LO has been build for Windows all the time using that and it works fine. In my opinion, the only case where it makes sense to use MinGW is for cross-compilation. There is just too much crack on Windows anyway, and it is a semi-miracle (well, make that the result of years of work) that the MSVC build under Cygwin works as nicely as it does. MinGW is available as cross-build toolchains pre-packaged in more or less official packages for many Linux distros including Debian, Fedora and openSUSE. Personally I use the mingw32 packages in the openSUSE Build Service, running on openSUSE. It is somewhat unclear how well thought-out the conditionals and code for MinGW inside the OOo-originated code in LibreOffice actually is. The little I have seen of it seems a bit randomish, with copy-pasting having been preferred to factoring out differences. The autogen.lastrun I use for my MinGW cross-compilation experimentation is: CC=ccache i686-w64-mingw32-gcc CXX=ccache i686-w64-mingw32-g++ CC_FOR_BUILD=ccache gcc CXX_FOR_BUILD=ccache g++ --build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32 --with-distro=LibreOfficeWin32 --disable-binfilter --disable-build-mozilla --disable-directx --disable-ext-nlpsolver --disable-ext-pdfimport --disable-ext-presenter-console --disable-ext-presenter-minimizer --disable-ext-report-builder --disable-ext-scripting-beanshell --disable-ext-scripting-javascript --disable-ext-wiki-publisher --disable-ext-wiki-publisher --disable-mozilla --disable-zenity --enable-python=system --with-external-tar=/mnt/hemulen/ooo/git/master/src --with-num-cpus=1 --with-max-jobs=1 --with-system-altlinuxhyph --with-system-boost --with-system-cairo --with-system-cppunit --with-system-curl --with-system-db --with-system-expat --with-system-gettext --with-system-hunspell --with-system-icu --with-system-libpng --with-system-libwpd --with-system-libwpg --with-system-libwps --with-system-libxml --with-system-libxslt --with-system-lpsolve --with-system-mythes --with-system-neon --with-system-openssl --with-system-redland --with-vendor=no iOS --- iOS is the operating system of Apple's mobile devices. Clearly for a device like the iPad it would be totally unacceptable to run a normal LibreOffice application with a overlapping windows and mouse-oriented GUI widgets. No work has been done (at least publicly) to design a touch GUI for LibreOffice, so the work on cross-compiling LibreOffice for iOS is extremely experimental, and of course partly pointless;) But it is interesting and fun nonetheless. Obviously it will make sense to build only a part of LibreOffice's code for iOS. Most likely all GUI-oriented code should be left out, and some iOS app that eventually wants to use the remaining bits will handle all its GUI in a platform-dependent manner. How well it will be possible to do such a split remains to be seen. As I said, this is highly experimental and just in its baby steps phase. Technically, one important special aspect of iOS is that apps are not allowed to load own dynamic libraries. (System libraries are used in the form of dynamic libraries, just like on MacOSX, of which iOS is a variant.) So all the libraries in LibreOffice that normally are shared libraries (DLLs on Windows, shared objects (.so) on Linux, dynamic libraries on MacOSX (.dylib)) need to be built as static archives instead. Obviously this will have some interesting consequences for how UNO is implemented and used. None of that has been spared much thought yet. The Apple tool-chain for iOS cross-building is available only for MacOSX, so that is where I have been doing it. Here is my autogen.lastrun for iOS (device): CXX=ccache /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++-4.2 -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk CC=ccache /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0 CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0 --with-distro=LibreOfficeiOS --with-external-tar=/Volumes/ooo/git/master/src --with-num-cpus=1 --with-max-jobs=1 And here for the iOS simulator: CXX=ccache /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/g++-4.2 -arch i386 -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk CC=ccache /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc-4.2 -arch i386 -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.3.sdk CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0 CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0 --with-distro=LibreOfficeiOS --with-external-tar=/Volumes/ooo/git/master/src --with-num-cpus=1 --with-max-jobs=1 --disable-librsvg --enable-debug Android ------- I don't know much about Android, but from a technical point of view it is a kind of Linux, of course. As far as I know it is allowed for an Android app to use shared objects, but if it isn't, then just the same approach as used on iOS will need to be used. As for the GUI, the same holds as said above for iOS. I have done my Android cross-compilation work on Linux (openSUSE in particular), but it could as well be done on MacOSX. The Android cross-buld tool-chain (the "Native Development Kit", or NDK) is available for Linux, MacOSX and Windows. (Trying to cross-compile from Windows will probably drive you insane.) Here is my autogen.lastrun for Android: SYSBASE=/home/tml/android-ndk-r5c/platforms/android-9/arch-arm CC=ccache /home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc --sysroot /home/tml/android-ndk-r5c/platforms/android-9/arch-arm CXX=ccache /home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-g++ --sysroot /home/tml/android-ndk-r5c/platforms/android-9/arch-arm -I /home/tml/android-ndk-r5c/sources/cxx-stl/gnu-libstdc++/include -I/home/tml/android-ndk-r5c/sources/cxx-stl/gnu-libstdc++/libs/armeabi-v7a/include -L/home/tml/android-ndk-r5c/sources/cxx-stl/gnu-libstdc++/libs/armeabi-v7a -fexceptions -frtti AR=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ar NM=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-nm OBJDUMP=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-objdump RANLIB=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ranlib STRIP=/home/tml/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-strip CC_FOR_BUILD=ccache gcc CXX_FOR_BUILD=ccache g++ --build=x86_64-unknown-linux-gnu --disable-zenity --with-distro=LibreOfficeAndroid --with-external-tar=/mnt/hemulen/ooo/git/master/src --disable-python --with-num-cpus=1 --with-max-jobs=1 PowerPC Mac OS X ---------------- Cross-compiling for PowerPC Mac OS X from Intel Mac OS X will probably be easy. The APIs available should after all be closely identical to those on Intel Mac OS X, and LibreOffice builds fine natively on PowerPC Mac already. I have just started experimenting with it. My autogen.lastrun looks like this: CC=ccache /Xcode3/usr/bin/gcc-4.0 -arch ppc CXX=ccache /Xcode3/usr/bin/g++-4.0 -arch ppc CC_FOR_BUILD=ccache /Xcode3/usr/bin/gcc-4.0 CXX_FOR_BUILD=ccache /Xcode3/usr/bin/g++-4.0 --build=i386-apple-darwin10.7.0 --host=powerpc-apple-darwin10 --disable-mozilla --disable-build-mozilla --with-external-tar=/Volumes/ooo/git/master/src That's all, thank you, and have a nice day. People with commit access, feel free to edit this document, and add yourself below. Sorry for writing now initially from such a personal point of view. --Tor Lillqvist <tlillqvist@novell.com>, <tml@iki.fi>