summaryrefslogtreecommitdiff
path: root/README.cross
diff options
context:
space:
mode:
authorTor Lillqvist <tml@iki.fi>2012-01-17 19:06:26 +0200
committerTor Lillqvist <tml@iki.fi>2012-01-17 19:12:15 +0200
commitee4fc40f63db751fe4d20419ea0f5bc7557e2414 (patch)
tree59ad33d832699688f04f9ed52eaba26259884108 /README.cross
parentc2c669db137b9ace3928612834ea080f3e661fef (diff)
Make it sound slightly less experimental and scary
Diffstat (limited to 'README.cross')
-rw-r--r--README.cross41
1 files changed, 20 insertions, 21 deletions
diff --git a/README.cross b/README.cross
index 45e1888253f2..86d656639d4b 100644
--- a/README.cross
+++ b/README.cross
@@ -14,7 +14,7 @@ github. I am not interested in that.
Cross-compilation of LibreOffice completely is not possible yet. Much
work has been done, "baby steps" for some platforms, much more for
others, but a lot remains. For iOS and Android this work is highly
-experimental and done mostly in my own spare time just for the hacking
+experimental, originally done in my spare time just for the hacking
pleasure. No promise, explicit or implied, is given that it will ever
be finished.
@@ -44,7 +44,7 @@ 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
+out nicely. In practise, many details needed to be handled. See
examples below.
@@ -122,8 +122,9 @@ for MinGW inside the OOo-originated code in LibreOffice actually
are. What I have noticed of it seems a bit randomish, with
copy-pasting having been preferred to factoring out differences.
-Most of the configuration settings are maintained in the LibreOfficeMinGW
-distro-config, so in your autogen.lastrun, you can use:
+Most of the configuration settings are maintained in the
+distro-configs/LibreOfficeMinGW.conf file, so in your autogen.lastrun,
+you can use:
CC=ccache i686-w64-mingw32-gcc
CXX=ccache i686-w64-mingw32-g++
@@ -131,8 +132,8 @@ CC_FOR_BUILD=ccache gcc
CXX_FOR_BUILD=ccache g++
--with-distro=LibreOfficeMinGW
-Alternatively, you can use something like the following; but the preferred way
-is to keep LibreOfficeMinGW distro up-to-date.
+Alternatively, you can use something like the following; but the
+preferred way is to keep the LibreOfficeMinGW.conf file up-to-date.
CC=ccache i686-w64-mingw32-gcc
CXX=ccache i686-w64-mingw32-g++
@@ -251,17 +252,15 @@ 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.
+GUI widgets. No work has been done (at least publicly) by others to
+design a touch GUI for LibreOffice, so that is something that needs to
+be done.
+
+Obviously it will make sense to use only a part of LibreOffice's code
+for iOS. Most likely lots of the GUI-oriented code should be left out,
+and some iOS app(s) 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.
Technically, one important special aspect of iOS is that apps are not
allowed to load own dynamic libraries. (System libraries are used in
@@ -310,10 +309,10 @@ or g++ won't find its headers like <bits/c++config.h>
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.
+From a technical point of view the core Android OS is Linux, but
+everything else is different. Unlike iOS, an Android app can use
+shared objects just fine, so that aspect of UNO doesn't need special
+handling.
As for the GUI, the same holds as said above for iOS.