<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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><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_547606551736199691gmail-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_547606551736199691gmail-s1" style="color:rgb(139,132,207)">1</span></p>
<p class="m_547606551736199691gmail-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_547606551736199691gmail-s2" style="color:rgb(210,143,90)">#import </span>"../../../include/<wbr>LibreOfficeKit/LibreOfficeKit.<wbr>h"</p></div><div><br></div></div></blockquote><div>The reason I added a C layer is two fold:</div><div>1) I needed one to make the init call anyway.</div><div>2) I got several problems using the kit pointer, and calling functions directly, it was clear that a lot of the calls was not converted correctly, e.g. swift does naturally not know about the something special strings in LO.</div><div><br></div><div>So in total I preferred supplying a bridgeheader, which tells exactly what are tested and will work.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><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></blockquote><div>Look in the .mk files in iOS.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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.<br></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></blockquote><div><br></div><div>I do not see a real difference between a framework (which is basically a library and a header file) and the current kit project ?</div><div><br></div><div>dylib files would be real preferencial, but how do you get those to work in iOS. iOS demand static libraries.</div><div> </div><div>rgds</div><div>jan I.</div></div></div></div>