<div dir="ltr"><div>Happy new year, very interesting work.</div><div><br></div><div>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.</div><div><br></div>> <span style="font-size:12.8px">try the -r flag which is for prelinking. you can see that in the .mk file</span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px">Couldn't get that to do anything. I also tried -flto=thin which supposedly can do incremental linking, but again little effect</span></div></div></blockquote><div><br></div><div>Look in iOS/<span style="color:rgb(0,0,0);font-family:Menlo;font-size:11px">CustomTarget_iOS_prelink.<wbr>mk, there you will find</span></div><div><br></div><p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">        $(IOSLD) -r -ios_version_min 11.1 \</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">            -syslibroot $(MACOSX_SDK_PATH) \</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">            -arch `echo $(CPUNAME) |  tr '[:upper:]' '[:lower:]'` \</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">            -o $(IOSOBJ) \</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">            $(WORKDIR)/CObject/ios/source/<wbr>LibreOfficeKit.o \</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">            `$(SRCDIR)/bin/lo-all-static-<wbr>libs` \</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">            $(call gb_StaticLibrary_get_target,<wbr>iOS_kitBridge)</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">        $(AR) -r $(IOSKIT) $(IOSOBJ)</span></p><div><br></div><div>which does prelinking (different from incremental linking). You can see it generated and .o file, which is then put into an archive.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px">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.</span></div></div></blockquote><div>??? xcode runs perfect on the command line, so I do not understand why you say it is impossible.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px">* 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</span></div></div></blockquote><div>This is as expected. The framework is basically a dylib so of course linking to that is a lot faster.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px">* It's only been tested on the simulator. Needs some more stuffing about to link the correct lib for device. </span></div></div></blockquote><div><br></div><div>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  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px">*** 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</span></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Why do you think just having 1 scheme is better ?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px">* 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</span></div></div></blockquote><div><br></div><div>It is a different approach, but one I like, we do however still need the C file.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px">* I tried to get a tile rendering both in the test and the app. No good. </span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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...</span></div><div><span style="font-size:12.8px">But even after creating one of those to render into a image, it crashes with an </span><span style="font-size:12.8px">uncaught exception of type com::sun::star::container::NoS<wbr>uchElementException (see pic of stack trace below) </span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px">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?</span></div></div></blockquote><div>My problem was more how to use the returned array in order to render it effectively.</div><div><br></div><div>The paintTile code is used both in the android version (see core/android) and the online (separate git repo), so it works.</div><div><br></div><div>You might have run into a problem with swift delivering a false type of array. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Anyway, I really think splitting into a Framework is the way to go - I think the rendering problems are probably independent of this. </span></div><div><span style="font-size:12.8px">It provides a good separation between app and library, and makes the app be able to be pure swift.</span></div><div><span style="font-size:12.8px">It would certainly make using LOK in another app much much easier, than trying to unpick the example app.</span></div></div></blockquote><div>Which example app ?</div><div><br></div><div>The old example app have been removed because it was very outdated.</div><div> </div><div>keep up the good work, I will get around to integrate part of it soon.</div><div><br></div><div>rgds</div><div>jan I.</div></div></div></div>