<div dir="ltr">Hi Jan,<div>The way I understand it is that the static libs, the .a files, aren't actually linked yet - they are just an archive of .o object files collected together.</div><div>When you link the app with the static lib it has to do a full read of the symbols in the .a file and write the relevant ones into the executable.</div><div>There are 1.3 million symbols in the .a file (from <span style="font-variant-ligatures:no-common-ligatures;background-color:rgba(0,0,0,0.96);color:rgb(244,244,244);font-family:Menlo;font-size:13px">nm libKit_X86_64_debug.a | wc -l</span> )</div><div>Adding -print_statistics to the linker flags gives this:</div><div><br></div><div><div> ld total time: 894.4 seconds ( 100.0%)</div><div> option parsing time: 11.0 milliseconds ( 0.0%)</div><div> object file processing: 0.1 milliseconds ( 0.0%)</div><div> resolve symbols: 612.3 seconds ( 68.4%)</div><div> build atom list: 0.0 milliseconds ( 0.0%)</div><div> passess: 486.3 milliseconds ( 0.0%)</div><div> write output: 281.6 seconds ( 31.4%)</div><div>pageins=447127, pageouts=2622, faults=3099715</div><div>processed 7 object files, totaling 476,732 bytes</div><div>processed 2 archive files, totaling 456,642,248 bytes</div><div>processed 32 dylib files</div><div>wrote output file totaling 324,771,884 bytes</div></div><div><br></div><div>Eg most of the time is spent reading symbols from the .a file, and then writing them into the executable.</div><div>I also played around of using ld independantly of XCode and just trying to link the .a file with no app and no swift involved - times were about the same.</div><div>So to improve the linking of the .a file I think the main game would be reducing the number of symbols in the .a. Probably not that practical.</div><div><br></div><div>So what I think you will get with a Framework project is actually linking the .a file, seperately to the application executable. That means you won't have that full link every time you build the app, but only when the framework needs to build. That's the theory, anyway.</div><div><br></div><div>iOS has allowed dylibs since iOS 8 and the introduction of Swift. In fact you can't produce a static lib with Swift, only a dylib.</div><div>For our Pdfium wrapper we produce a static lib out of the Pdfium code itself, and link that in a framework project with the swift wrappers, to produce a dylib which is a swift module that can be imported into an app. Beside the linking benefits this then gives you a nice encapsulated library that is easy to consume from swift.</div><div><br></div><div>If I have time over the next couple of days I'll have a go at creating a framework to see if it does actually behave as I expect.</div><div><br></div><div>Cheers</div><div><br></div><div>Jon</div><div><br></div> </div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 30, 2017 at 2:43 AM, jan iversen <span dir="ltr"><<a href="mailto:jani@apache.org" target="_blank">jani@apache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Please do not misunderstand my comments, I am open to any enhancements especially on the linking process of the app...but I would like to see a benefit of the changes.<div><br></div><div>rgds</div><div>jan I.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 29 December 2017 at 09:36, Jon Nermut <span dir="ltr"><<a href="mailto:jon.nermut@gmail.com" target="_blank">jon.nermut@gmail.com</a>></span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the reply Jan.<div><br></div><div>My main point about BridgeLOKit was that you don't really need to add another FFI on top of the existing LibreOfficeKit.h FFI.</div><div>Swift can import and use the existing _LibreOfficeKit / _LibreOfficeKitClass and _LibreOfficeKitDocument / _LibreOfficeKitDocumentClass structs and their functions just fine. Swift actually has excellent C integration (and non-existent C++). To do so I just added:</div><div><br></div><div> <p class="m_7881139699775081519m_7086953373973236056gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(210,143,90);background-color:rgb(40,43,53)">#define LOK_USE_UNSTABLE_API <span class="m_7881139699775081519m_7086953373973236056gmail-s1" style="color:rgb(139,132,207)">1</span></p> <p class="m_7881139699775081519m_7086953373973236056gmail-p2" style="margin:0px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(228,67,71);background-color:rgb(40,43,53)"><span class="m_7881139699775081519m_7086953373973236056gmail-s2" style="color:rgb(210,143,90)">#import </span>"../../../include/LibreOfficeK<wbr>it/LibreOfficeKit.h"</p></div><div><br></div><div>Into lokit-Bridging-Header.h, and the struct types mentioned above are usable directly within Swift without anymore C needed - LibreOfficeKitWrapper.swift is an example of using the functions from these structs directly, and wrapping the C struct pointers in swift classes, making them encapsulated and easier to use. </div><div>The exception being the lok_init functions, which need to be included and called from within a C file.</div><span><div><br></div><div>>> The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig file, but I will need to check that.</div><div><br></div></span><div>Oh, I couldn't find it... where is it supposed to be generated to? I changed the the path settings in LibreOfficeLight.xcodeproj like this:</div><div><br></div><div><div>-<span style="white-space:pre-wrap"> </span>LIBRARY_SEARCH_PATHS = /Users/jani/LO/core/ios/genera<wbr>ted/;</div><div>+<span style="white-space:pre-wrap"> </span>LIBRARY_SEARCH_PATHS = $PROJECT_DIR/../generated/;</div></div><div><br></div><div>I tried a few settings on the linking, couldn't make it better. Need to find a way to work out what its doing... I'll have more of a play.</div><div>My suggestion is to split the C integration, and it's swift wrappers, into a separate Framework project, and let that produce a dylib.</div><div>That should link pretty much instantly to the app, and should only rebuild and link when the libreoffice lib changes, or the code in the Framework</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers</div><span class="m_7881139699775081519HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra">Jon</div></font></span><div><div class="m_7881139699775081519h5"><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 29, 2017 at 6:38 PM, jan iversen <span dir="ltr"><<a href="mailto:jani@apache.org" target="_blank">jani@apache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">Hi</div><div dir="auto"><br></div><div dir="auto">adding dev list to reply, so that others might benefit from the info.</div><div dir="auto"><br></div><div class="gmail_quote"><span class="m_7881139699775081519m_7086953373973236056gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Hope you don't mind the unsolicited email, I figured you were the guy to talk to about this from the git commits.</div><div></div></div></blockquote></span><div dir="auto">I am working actively on creating a version of LO for the iPad.</div><span class="m_7881139699775081519m_7086953373973236056gmail-"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>So I got it compiling via lode, with just a couple of hitches (had to install libassuan, had to make sure to use the make out of lode, and there is a hard coded LIBRARY_SEARCH_PATH to /Users/jani/... in the ios project file)</div></div></blockquote></span><div dir="auto">I do not understand why you had to install extra libraries. I work on high sierra with xcode 9 and have not installed that library.</div><div dir="auto"><br></div><div dir="auto">The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig file, but I will need to check that.</div><div dir="auto"><br></div><div dir="auto">There are 2 projects, but I assume you talk about the kit project?</div><span class="m_7881139699775081519m_7086953373973236056gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div><div>1. The app doesnt actually attempt to render yet? Were you planning on using CATiledLayer for that? I've used it a couple of times (for PDFs)... it's fun</div></div></blockquote><div dir="auto"><br></div></span><div dir="auto">No it doesn’t. As you probably have seen the render function is near empty, I am strugling to find out what the tiled calls returns and how to use that in the swift app.</div><span class="m_7881139699775081519m_7086953373973236056gmail-"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div></div><div>2. The static lib, and the compiled app, are pretty fat. (At least in debug for the simulator - ~400mb, I havent tried the release build yet). Too fat to embed in my app, it would have to be a separate app. Any insight as to whether this could ever be cut down to a reasonable size?</div></div></blockquote></span><div dir="auto">Well is it actually quite reduced. LO is simply big.</div><span class="m_7881139699775081519m_7086953373973236056gmail-"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div></div><div>3. The link time on the app is outrageously slow at the moment - at least on my macbook pro - I guess this is related to the size and number of symbols in the static lib. That's what the dummy.c file is all about? Needs to be quarantined from the app somehow. Perhaps by keeping it in a Framework project? Or cutting down its size. I was too scared to turn on LTO...</div></div></blockquote></span><div dir="auto">The link time is my biggest problem, linking the kit is a fraction of linking the app, and It seems to be the swift interface that is the problem.</div><div dir="auto"><br></div><div dir="auto">dummy.c is to link without the kit, and it is automatically quarantined, look in build phases, where you will see it is not being compiled.</div><span class="m_7881139699775081519m_7086953373973236056gmail-"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div></div><div>4. Just wondering the reasoning for starting a new C interface into LibreOfficeKit (eg <span style="background-color:rgb(40,43,53);color:rgb(147,201,106);font-family:Menlo;font-size:11px">BridgeLOkit_*</span> )?</div></div></blockquote></span><div dir="auto">How else would you make a C/C++ interface for swift ?</div><span class="m_7881139699775081519m_7086953373973236056gmail-"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div></div><div>I had success in talking to the main LibreOfficeKit.h file directly from swift by including it in the bridging file. Using it directly would take away a lot of duplication needed to flesh out BridgeLOkit. Granted the main C api isnt that friendly to use, but IMHO it would be better to do the wrapping and making the API friendly on the Swift side, rather than another layer of C, which then still needs swift friendly classes around it. </div><div>The main problem is with the way LibreOfficeKitInit works (which seems weird...), for which I reused <span style="background-color:rgb(40,43,53);color:rgb(147,201,106);font-family:Menlo;font-size:11px">BridgeLOkit_Init</span> and added a func to get the pointer to kit out.</div><div>See the attached LibreOfficeKitWrapper.swift file - it has just a couple wrapped functions done but you can see what I mean. Needs the rest filled in and memory handling done.</div></div></blockquote></span><div dir="auto">Functions not declared in the bridge are unlikely to work in swift (according to the swift documentation).</div><span class="m_7881139699775081519m_7086953373973236056gmail-"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div></div> <div><br></div><div>I've done this before for Pdfium - which also has a C based FFI. We created a framework called PdfiumSwift which had swift classes like PDFDocument, PDFPage etc which wrapped the C interface and made consuming it easy in Swift. We hooked the memory management off the swift deinit() etc. It used an internal private module to consume the C API so it was just the Swift API exposed outside of the framework / module.</div></div></blockquote></span><div dir="auto">this is basically the same the kit project does, except it does not use classes.</div><div dir="auto"><br></div><div dir="auto">rgds</div><div dir="auto">jan i</div><span class="m_7881139699775081519m_7086953373973236056gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div></div><div><br></div><div>Once the basic wrapping is done, then these classes provide a good place to add stuff like converting the raw tiles into iOS friendly bitmaps etc.</div><div><br></div><div>Anyway, good job on getting it this far, and happy new year.</div><div><br></div><div>Cheers</div></div><div><div><br></div><div><br></div><div>Jon Nermut</div> </div></blockquote></span></div></div><span class="m_7881139699775081519m_7086953373973236056gmail-HOEnZb"><font color="#888888"><div dir="ltr">-- <br></div><div class="m_7881139699775081519m_7086953373973236056gmail-m_-3031170130536485458gmail_signature">Sent from My iPad, sorry for any misspellings.</div> </font></span></blockquote></div><br></div></div></div></div> </blockquote></div></div></div><br></div> </blockquote></div><br></div>