Losing my mind trying to properly build CBL into a complex target

[Ben Kennedy]

Hey all,

I have a framework target, an action extension target, and an app target. The app embeds the first two. The framework provides code shared between both the extension and the app. Some of this code uses CBL; hence, CBL must be linked into the framework. Other code distinct to the app also calls CBL.

Up until now, the framework has been built only from Objective-C source, and I've been able to make everything work. All hell has broken loose recently once I decided to add a Swift class (inheriting from CBLModel) to the framework. Biggest problem: CBL is not a modular framework, and thus apparently cannot be linked into a product containing any Swift.

It appeared that I could convince Xcode to cope if I first wrote my own 'Modules/module.modulemap' file into the CouchbaseLite.framework bundle. Indeed, this permits the framework to link. Unfortunately, I now get a slew of other weird side effects (such as methods in completely unrelated classes returning UIViews that the compiler inexplicably interprets to be CBLViews).

I recognize that I'm tiptoeing along a ledge trying to tie this all together, and it's time to reach out for some professional help. Oh, did I mention that I'm importing CBL via CocoaPods? No doubt that doesn't make things any easier.

Searching the archives, it appears that similar questions were raised by Kevin Lord about a year and a half ago, but as far as I can tell no further discussion ensued: https://groups.google.com/forum/#!searchin/mobile-couchbase/framework%7Csort:relevance/mobile-couchbase/q2kLQv01LKQ/AIjwb_OWLvUJ

What is the correct way to build CBL into a composite project as described in my opening paragraph?

thanks,

-ben

[Jens Alfke]

> On Aug 17, 2016, at 3:55 PM, Ben Kennedy <ben.k...@kashoo.com> wrote:
>
> Hey all,
>
> I have a framework target, an action extension target, and an app target. The app embeds the first two. The framework provides code shared between both the extension and the app. Some of this code uses CBL; hence, CBL must be linked into the framework. Other code distinct to the app also calls CBL.

Are you using the regular static-library build of Couchbase Lite? If so, you should switch to using the dynamic framework. Currently the only way to get that is to build it yourself, from the “CBL iOS Framework” target. (Oh wait, I think if you use Carthage it will also build this, because Carthage only builds dynamic frameworks.)

—Jens

[Ben Kennedy]

On Wednesday, August 17, 2016 at 2:13:48 PM UTC-7, Jens Alfke wrote:

Are you using the regular static-library build of Couchbase Lite? If so, you should switch to using the dynamic framework. Currently the only way to get that is to build it yourself, from the “CBL iOS Framework” target. (Oh wait, I think if you use Carthage it will also build this, because Carthage only builds dynamic frameworks.)

Indeed, since we're acquiring Couchbase Lite from CocoaPods, it has been the static version. (Are there plans to distribute a dylib build? Or perhaps more poignantly, why doesn't the CocoaPods distribution download and build the source like virtually every other pod does?)

I had not heretofore explored Carthage, but I did set it up yesterday on your tip. That looks like another option to keep in mind; thanks.

I think I'm going to put up with the "slap in a modulemap" hack for now though, as it appears to get the job done without further complicating our build pipeline right now—even though I expect we are going to be dealing with duplicately-linked symbols…

cheers,

-ben

[Jens Alfke]

On Aug 18, 2016, at 7:04 PM, Ben Kennedy <ben.k...@kashoo.com> wrote:

Indeed, since we're acquiring Couchbase Lite from CocoaPods, it has been the static version. (Are there plans to distribute a dylib build? Or perhaps more poignantly, why doesn't the CocoaPods distribution download and build the source like virtually every other pod does?)

CocoaPods didn’t use to be flexible enough to build our project (which is pretty complex.) It probably is now, but no one’s put the work into trying it.

Also, our build team prefers binary downloads so that they can build and qualify the binaries and we know exactly what customers are using.

In the near future, whenever we can drop support for iOS 7, we’ll probably switch to only having a dynamic framework. The whole static-framework approach was just to work around iOS apps’ inability to load dynamic libraries.

—Jens

[Ben Kennedy]

On 19 Aug 2016, at 6:17 am, Jens Alfke <je...@couchbase.com> wrote:

> CocoaPods didn’t use to be flexible enough to build our project (which is pretty complex.) It probably is now, but no one’s put the work into trying it.

Fair enough. I would be inclined to start looking in to this myself, if only I could get past a house-of-cards situation I've somehow introduced by adding a swift file to our shared framework and resume being able to get our project to build at all. (And my "modulemap hack" described yesterday has, of course, proven to be a non-starter because of duplicately-linked code. Sigh.)

> In the near future, whenever we can drop support for iOS 7, we’ll probably switch to only having a dynamic framework. The whole static-framework approach was just to work around iOS apps’ inability to load dynamic libraries.

Cool; I'll be looking forward to that.

Carthage looked like a possibility, but it seems to require user interaction simply to do a "carthage update", so that's a no-go. Maybe a git submodule is the next thing to explore in the mean time.

thanks,

-ben