Re: Annoying Superclass Implemenation Warning
Re: Annoying Superclass Implemenation Warning
- Subject: Re: Annoying Superclass Implemenation Warning
- From: Chris Hanson <email@hidden>
- Date: Mon, 21 Jan 2008 16:40:37 -0800
On Jan 21, 2008, at 3:52 PM, Steve Christensen wrote:
What Mike had suggested doing is to create a target that builds a
framework containing the common class. Your plugin targets are then
dependent on that target and also link against the framework it
builds. When you install, your plugins go in the prefs panes folder
and the custom framework goes in the frameworks folder. Then when
plugin #1 loads, it forces the framework to load and register the
common class. When plugin #2 loads, the class has already been
registered, once, by the framework so there's no second attempt at
registration.
Another solution is to implement your common base class in your
application itself, and make your plug-ins link against the
application by specifying its binary as their Bundle Loader. Xcode's
documentation has an overview of this build setting, or see the -
bundle_loader description in the linker (ld) manual page <x-man-page://1/ld
>.
In general, however, the
Framework
/ \
Application Plug-ins
pattern is a good one to follow if you're implementing an application
with a plug-in architecture. It will help ensure that your API is
independently testable, make it easier for yourself and third-party
developers to create additional projects that link against your
framework (you can just ship the headers and docs for your public API
within it rather than strip them out), and so on.
You can even embed the framework in the application's Frameworks
folder using an install name that starts with @exectuable_path/../
Frameworks (as is usual for frameworks embedded within an application)
and then have your plug-ins link against that. This will work because
the application that loads the plug-ins is what's referenced by
@executable_path; thus the plug-ins' framework link will also succeed
both at build time and at run time.
-- Chris
PS - One suggestion for anyone implementing applications that use plug-
ins: Use a custom path extension for your plug-ins. Neither the
".plugin" nor ".bundle" path extension says anything about whether a
particular plug-in will work with a particular host application.
Using a generic path extension may lead people to believe they will.
PPS - One more suggestion: If you have "stock" or plug-ins that ship
with your application, embed them in your application's standard plug-
ins folder using a Copy Files build phase in your Application target.
This will enable you to do "drag-install" deployment of just
MyApp.app, while letting you refactor your application's internals
into plug-ins.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden