> 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?
_______________________________________________
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
