On Fri, May 13, 2016, at 03:23 AM, Jeff Szuhay wrote: > > > On May 11, 2016, at 5:11 PM, Jeff Szuhay <j...@szuhay.org> wrote: > >> On May 11, 2016, at 12:08 AM, Jens Alfke <j...@mooseyard.com> wrote: > >>> On May 10, 2016, at 11:05 PM, Jeff Szuhay <j...@szuhay.org > >>> <mailto:j...@szuhay.org>> wrote: > >>> > >>> Class Foo is a base class. It is subclassed in BundleA, BundleB, … > >>> BundleZ. > >> > >> Where is Foo itself implemented? If there are copies of the Foo class in > >> each bundle then yeah, you’ll get that warning. > >> > >>> Is there a better way to do it? I can’t currently how to have a singleton > >>> base class > >>> implementation that is shared among two or more bundles. > >> > >> Put the base class (and any other shared code) in a framework that each of > >> your bundles links against. > >> > >> —Jens > > > > Foo is common to all plug-ins of the app but not needed in the app itself > > nor by anything else in the system. > > > > That was definitely the “right way:” make a framework of the base classes > > and store it in the app bundle. > > Each plug-in links against the framework. > > > > But, sheesh, that was painful to figure out. > > > > Thanks, Jens. > > > What was particularly painful was how to configure each Xcode > sub-project to see the framework. I had to > fiddle around with this for an inordinate amount of time. I feel the > framework approach and some basic steps > should, at the very least, be included in the READ.ME file for Apple’s > sample BundleLoader project. > > But, just to be clear, the BundeLoader project is awesome (among many > others). Thank you, Apple. > > I’m still trying to figure out the difference between private framework > headers and project framework headers. > > So far, I’ve learned that > 1) Project headers are only available within the framework and not to any > other “consumer” of the framework. > Which is to say, my bundles, which “consume" the framework, cannot > see project headers. > 2) Private heads are available to consumers of the framework but only at > compile/link time. They are not anywhere > in the app bundle — which is exactly what I want. > One downside to this is that if I change a framework header I have to > rebuild the framework to get the changes > in the right place for the bundles to see the changes. Minor > inconvenience. > 3) Public headers become available for everyone who looks in the app > bundle. They are moved there for all to see. > (not what I want). > > Did I learn correctly?
Not quite. Private headers get copied into the Framework bundle, but in a PrivateHeaders subfolder instead of the regular Headers folder. This way your clients can use your private API, and then when everything is built you can go through and strip all PrivateHeaders folders from your app bundle. This sounds like exactly what you want. Note: I haven’t actually done this in the face of codesigning. Not sure if PrivateHeaders is considered part of the framework’s seal. --Kyle _______________________________________________ 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
