Happy new year, very interesting work. I have just updated my master, and now I see your problem with libassuan, which I am trying to solve. It is being build locally but not copied to the right place. I did a couple of commits yesterday to a.o. include your idea on how to make LIBRARY_PATH relative, thanks for that.
> try the -r flag which is for prelinking. you can see that in the .mk file > Couldn't get that to do anything. I also tried -flto=thin which supposedly > can do incremental linking, but again little effect > Look in iOS/CustomTarget_iOS_prelink.mk, there you will find $(IOSLD) -r -ios_version_min 11.1 \ -syslibroot $(MACOSX_SDK_PATH) \ -arch `echo $(CPUNAME) | tr '[:upper:]' '[:lower:]'` \ -o $(IOSOBJ) \ $(WORKDIR)/CObject/ios/source/LibreOfficeKit.o \ `$(SRCDIR)/bin/lo-all-static-libs` \ $(call gb_StaticLibrary_get_target,iOS_kitBridge) $(AR) -r $(IOSKIT) $(IOSOBJ) which does prelinking (different from incremental linking). You can see it generated and .o file, which is then put into an archive. > Nah it would be very difficult if not impossible to get a swift Framework > built through make - one thing that I've learnt in iOS development is don't > fight XCode. You'ld end up just calling xcodebuild anyway, which still > needs the project set up correctly. > ??? xcode runs perfect on the command line, so I do not understand why you say it is impossible. > > * The linking of the framework takes just as long as the app did. But once > you have it built, as long as you don't touch the framework, rebuilds of > the app are fast > This is as expected. The framework is basically a dylib so of course linking to that is a lot faster. I am still not convinced making a framework is a better solution than just linking a dylib directly, at least I do not see the advantages and at least one disadvantage, one more xcode project to maintain. > * It's only been tested on the simulator. Needs some more stuffing about > to link the correct lib for device. > dylib works very well in the simulator, my first test on my iPad (iOS 11.2) did not turn out very well. I am also looking into another problem, it seems that the App Store, still only allows upload of statically linked *** The way it's set up in the app at the moment with 3 schemes isn't as it > should be - you should have just one scheme, and use Configuration is for > debug/release, and platform/arch for simulator vs device. This will work ok > in the app once the framework is configured to link the correct .a file. > Which I will sort out if you move forward with this > The reason for using different schemes, is that the xcode doc recommends it, and it make the use simpler, since you just have to select a scheme. Why do you think just having 1 scheme is better ? > * I built out the Swift wrappers to cover all of the LibreOfficeKit > functions. Have a look at Document.swift in particular. The next step would > be to make an extension of Document to make iOS friendly methods for eg > rendering to a UIImage > It is a different approach, but one I like, we do however still need the C file. > * I tried to get a tile rendering both in the test and the app. No good. > > Firstly I was trying to pass a byte buffer to paintTile as per the method > signature, but it force casts that param to a CGContextRef a couple of > layers down... > But even after creating one of those to render into a image, it crashes > with an uncaught exception of type > com::sun::star::container::NoSuchElementException > (see pic of stack trace below) > Which took me deep into debugging core LibreOffice, which I didn't really > want to be, and was a bit frustrating. Maybe I'm missing some init code, or > passing the wrong params. > Feels like it might be bitrot of this tiling code that was written as a > POC in 2015 or so? I wonder when the last time it worked was. You mentioned > that you couldn't get it working either? > My problem was more how to use the returned array in order to render it effectively. The paintTile code is used both in the android version (see core/android) and the online (separate git repo), so it works. You might have run into a problem with swift delivering a false type of array. > Anyway, I really think splitting into a Framework is the way to go - I > think the rendering problems are probably independent of this. > It provides a good separation between app and library, and makes the app > be able to be pure swift. > It would certainly make using LOK in another app much much easier, than > trying to unpick the example app. > Which example app ? The old example app have been removed because it was very outdated. keep up the good work, I will get around to integrate part of it soon. rgds jan I.
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice