>> On Apr 4, 2018, at 9:25 AM, Redler Eyal <e...@mellel.com> wrote: >> >> We are aware that the following are possible solutions to the problem: >> a. Switch to use the same version of OpenCV as our client. >> b. Build our framework as a dynamic library (where we a supposed to be able >> to hide openCV inside) >> Both of these options are not optimal for us and we trying to see if we have >> any other option. > > Those are the only options I know will work. (But I'm not a linker expert, > and it may be that you could get the single-object pre-link to work.) > > I also work on a 3rd party iOS SDK*; version 1.x was shipped as a static > library, but it was such a pain in the butt in many ways. We only did it that > way because we started back before iOS apps were allowed to contain dynamic > libraries. In 2.0 we happily switched to a framework. > > I would highly recommend switching to a dynamic library (actually a > framework**.) It's the way things are Supposed To Work™, and it's a lot > cleaner. > > —Jens > > * https://github.com/couchbase/couchbase-lite-ios/ > ** Apple will reject submissions that include 'bare' dylibs in the app bundle.
We have two issues with the dynamic framework 1. It makes it easier to pirate our technology (having our stuff neatly packaged seperaterly) 2. (More importantly) It makes the client's binary larger since it will have to include our full library, including simulator code. (correct me if I'm wrong) Eyal _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
