mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
416e098e20356ba1af30d0ab1f4a8b51a2c669cb
libreoffice/ios/Executable_LibreOffice.mk

52 lines
1.4 KiB
Makefile
Raw Normal View History

More hacking on an iOS "Viewer" app that doesn't do much anything yet The Viewer app is intended to eventually resemble the experimental Android DocumentLoader app. Build using the gbuild mechanism, which is also invoked from an Xcode project. This seems to work out fine, the resulting app installs at least on the simulator, and you can debug all the LO code involved even if Xcode (obviously) has no knowledge of the LO source files/classes/etc. Change-Id: Ic96178d80b8d6467cac969b29e37f0d39513acf9
2013-01-03 13:29:08 +02:00
# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
#
Refactor the iOS Viewer app and rename it to "LibreOffice" No, it isn't any closer to being "ready" despite the name, but still, using the current approach, it clearly isn't restricted to be just a viewer. Also drop the verbose LOViewer prefix from class and file names in it. Change-Id: Ib4e8a31d6fa1b35169ee98cf2aa8f0f22957164c
2013-03-28 23:16:12 +02:00
$(eval $(call gb_Executable_Executable,LibreOffice))
More hacking on an iOS "Viewer" app that doesn't do much anything yet The Viewer app is intended to eventually resemble the experimental Android DocumentLoader app. Build using the gbuild mechanism, which is also invoked from an Xcode project. This seems to work out fine, the resulting app installs at least on the simulator, and you can debug all the LO code involved even if Xcode (obviously) has no knowledge of the LO source files/classes/etc. Change-Id: Ic96178d80b8d6467cac969b29e37f0d39513acf9
2013-01-03 13:29:08 +02:00
Refactor the iOS Viewer app and rename it to "LibreOffice" No, it isn't any closer to being "ready" despite the name, but still, using the current approach, it clearly isn't restricted to be just a viewer. Also drop the verbose LOViewer prefix from class and file names in it. Change-Id: Ib4e8a31d6fa1b35169ee98cf2aa8f0f22957164c
2013-03-28 23:16:12 +02:00
$(eval $(call gb_Executable_use_api,LibreOffice,\
More hacking on an iOS "Viewer" app that doesn't do much anything yet The Viewer app is intended to eventually resemble the experimental Android DocumentLoader app. Build using the gbuild mechanism, which is also invoked from an Xcode project. This seems to work out fine, the resulting app installs at least on the simulator, and you can debug all the LO code involved even if Xcode (obviously) has no knowledge of the LO source files/classes/etc. Change-Id: Ic96178d80b8d6467cac969b29e37f0d39513acf9
2013-01-03 13:29:08 +02:00
udkapi \
offapi \
))
Refactor the iOS Viewer app and rename it to "LibreOffice" No, it isn't any closer to being "ready" despite the name, but still, using the current approach, it clearly isn't restricted to be just a viewer. Also drop the verbose LOViewer prefix from class and file names in it. Change-Id: Ib4e8a31d6fa1b35169ee98cf2aa8f0f22957164c
2013-03-28 23:16:12 +02:00
$(eval $(call gb_Executable_use_externals,LibreOffice,\
Need boost_headers Change-Id: Ic0d13034a37ba354000de18e6f97b9cc31857bcb
2013-01-30 11:42:47 +02:00
boost_headers \
More hacking on an iOS "Viewer" app that doesn't do much anything yet The Viewer app is intended to eventually resemble the experimental Android DocumentLoader app. Build using the gbuild mechanism, which is also invoked from an Xcode project. This seems to work out fine, the resulting app installs at least on the simulator, and you can debug all the LO code involved even if Xcode (obviously) has no knowledge of the LO source files/classes/etc. Change-Id: Ic96178d80b8d6467cac969b29e37f0d39513acf9
2013-01-03 13:29:08 +02:00
iconv \
zlib \
))
Refactor the iOS Viewer app and rename it to "LibreOffice" No, it isn't any closer to being "ready" despite the name, but still, using the current approach, it clearly isn't restricted to be just a viewer. Also drop the verbose LOViewer prefix from class and file names in it. Change-Id: Ib4e8a31d6fa1b35169ee98cf2aa8f0f22957164c
2013-03-28 23:16:12 +02:00
$(eval $(call gb_Executable_use_system_darwin_frameworks,LibreOffice,\
More hacking on an iOS "Viewer" app that doesn't do much anything yet The Viewer app is intended to eventually resemble the experimental Android DocumentLoader app. Build using the gbuild mechanism, which is also invoked from an Xcode project. This seems to work out fine, the resulting app installs at least on the simulator, and you can debug all the LO code involved even if Xcode (obviously) has no knowledge of the LO source files/classes/etc. Change-Id: Ic96178d80b8d6467cac969b29e37f0d39513acf9
2013-01-03 13:29:08 +02:00
Foundation \
CoreFoundation \
CoreGraphics \
CoreText \
UIKit \
))
Need to have native-code.cxx as a separate file for the LibreOffice app The executable of the LibreOffice app (which as such at the moment doesn't work, since the tiled rendering changes) is built using gbuild, and thus we can't generate the native-code snippet in the CustomTarget that builds the app bundle, but need it already when building the executable. This is one wayt to handle that. Change-Id: Ifdab40c970e93b1f2608cefc637df8a8e5396efe
2014-01-01 18:37:02 +02:00
$(eval $(call gb_Executable_add_generated_cxxobjects,LibreOffice,\
CustomTarget/ios/LibreOffice/native-code \
))
$(call gb_CustomTarget_get_workdir,ios/LibreOffice)/native-code.cxx :
mkdir -p `dirname $@`
$(SRCDIR)/solenv/bin/native-code.py \
-g extended_core -g writer \
> $@
Refactor the iOS Viewer app and rename it to "LibreOffice" No, it isn't any closer to being "ready" despite the name, but still, using the current approach, it clearly isn't restricted to be just a viewer. Also drop the verbose LOViewer prefix from class and file names in it. Change-Id: Ib4e8a31d6fa1b35169ee98cf2aa8f0f22957164c
2013-03-28 23:16:12 +02:00
$(eval $(call gb_Executable_add_objcxxobjects,LibreOffice,\
ios/experimental/LibreOffice/LibreOffice/lo \
More hacking on an iOS "Viewer" app that doesn't do much anything yet The Viewer app is intended to eventually resemble the experimental Android DocumentLoader app. Build using the gbuild mechanism, which is also invoked from an Xcode project. This seems to work out fine, the resulting app installs at least on the simulator, and you can debug all the LO code involved even if Xcode (obviously) has no knowledge of the LO source files/classes/etc. Change-Id: Ic96178d80b8d6467cac969b29e37f0d39513acf9
2013-01-03 13:29:08 +02:00
))
Refactor the iOS Viewer app and rename it to "LibreOffice" No, it isn't any closer to being "ready" despite the name, but still, using the current approach, it clearly isn't restricted to be just a viewer. Also drop the verbose LOViewer prefix from class and file names in it. Change-Id: Ib4e8a31d6fa1b35169ee98cf2aa8f0f22957164c
2013-03-28 23:16:12 +02:00
$(eval $(call gb_Executable_add_objcobjects,LibreOffice,\
ios/experimental/LibreOffice/LibreOffice/AppDelegate \
ios/experimental/LibreOffice/LibreOffice/main \
ios/experimental/LibreOffice/LibreOffice/View \
ios/experimental/LibreOffice/LibreOffice/ViewController \
Re-work the vcl aspects of the iOS port Don't try to use similar code as for OS X to manage windows, events etc. I.e. don't use UIKit in vcl to do that. Instead, just do as in the Android port, use the "headless" vcl backend. Do keep using CoreText, though, not FreeType & fontconfig. Start changing the iOS "Viewer" app to correspond to the Android "desktop" app (so it should be renamed). Work in progress since a long time, several crucial details still missing, but committing for now. Change-Id: Iac5fbf8def415e4d0d21e5200450a373420ad7ee
2013-03-20 09:07:52 +02:00
))
# Mark the executable as depending on all libraries so that it gets
# rebuilt if any library has been rebuilt. Avoids need for "make
# ios.clean".
Use the lo-all-static-libs script Change-Id: Id2bef2696d0bdc618d2fc53658ad8ba23bbad310
2013-11-22 17:05:19 +02:00
$(WORKDIR)/LinkTarget/Executable/LibreOffice : $(shell $(SRCDIR)/bin/lo-all-static-libs)
Re-work the vcl aspects of the iOS port Don't try to use similar code as for OS X to manage windows, events etc. I.e. don't use UIKit in vcl to do that. Instead, just do as in the Android port, use the "headless" vcl backend. Do keep using CoreText, though, not FreeType & fontconfig. Start changing the iOS "Viewer" app to correspond to the Android "desktop" app (so it should be renamed). Work in progress since a long time, several crucial details still missing, but committing for now. Change-Id: Iac5fbf8def415e4d0d21e5200450a373420ad7ee
2013-03-20 09:07:52 +02:00
More hacking on an iOS "Viewer" app that doesn't do much anything yet The Viewer app is intended to eventually resemble the experimental Android DocumentLoader app. Build using the gbuild mechanism, which is also invoked from an Xcode project. This seems to work out fine, the resulting app installs at least on the simulator, and you can debug all the LO code involved even if Xcode (obviously) has no knowledge of the LO source files/classes/etc. Change-Id: Ic96178d80b8d6467cac969b29e37f0d39513acf9
2013-01-03 13:29:08 +02:00
# vim: set ts=4 sw=4 et:
Reference in New Issue Copy Permalink