Re: LibreOfficeLight / iOS

On 29 December 2017 at 09:36, Jon Nermut <jon.nermut@gmail.com> wrote:

> Thanks for the reply Jan.
>
> My main point about BridgeLOKit was that you don't really need to add
> another FFI on top of the existing LibreOfficeKit.h FFI.
> 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:
>
> #define LOK_USE_UNSTABLE_API 1
>
> #import "../../../include/LibreOfficeKit/LibreOfficeKit.h"
>
> The reason I added a C layer is two fold:
1) I needed one to make the init call anyway.
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.

So in total I preferred supplying a bridgeheader, which tells exactly what
are tested and will work.


> > > The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig file, but
> I will need to check that.
>
> 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:
Look in the .mk files in iOS.


> 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.
> My suggestion is to split the C integration, and it's swift wrappers, into
> a separate Framework project, and let that produce a dylib.
> 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

I do not see a real difference between a framework (which is basically a
library and a header file) and the current kit project ?

dylib files would be real preferencial, but how do you get those to work in
iOS. iOS demand static libraries.

rgds
jan I.