Suggestions for easier plugin development

[GoogleCodeExporter]

In developing a MacFusion plugin  (XgridFS), I found the following 
"improvements" could help:

1. change the build settings of the MacFusion app to:

GCC_SYMBOLS_PRIVATE_EXTERN=NO
STRIPFLAGS="-S" (not sure it is even necessary)

This way, extern NSString constants are accessible by the linker when compiling 
plugins (see 
below)

2. in the plugin, no need to compile the MacFusionConstants.m (which duplicates 
the symbols or 
overwrites them? Not sure how the linker works when loading the plugin in the 
app, that already 
has the symbols). Remove the file from the plugin target. Instead, use the 
following build setting:

BUNDLE_LOADER = $BUILT_PRODUCTS_DIR/MacFusion.app/Contents/MacOS/MacFusion

(this works if the plugin dev also builds MacFusion; otherwise, the path could 
be /Applications/
MacFusion.app/Contents/MacOS/MacFusin).

This way, after compiling the plugin, the linker will ignore undefined symbols 
that are anyway 
present in the executable that will ultimately load the bundle (and this 
executbale is... 
MacFusion!). This is where step 1 will help: BUNDLE_LOADER will indeed contain 
the potentially 
missing symbols.
Read also http://talblog.info/archives/2007/05/look_ma_no_fram.html for instance

3. The headers for the protocols and the MacFusionConstants should be copied in 
a 'Headers' 
subdir in the MacFusion package app.

Points 1-3 make it much easier to develop a plugin outside of the MacFusion 
Xcode project, and 
without having the MacFusion source (in particular MacFusionConstants.m). With 
the headers 
included, the bare minimum SDK is then actually included in the MacFusion app 
package itself.

4. For some reason, the target MacFusion copies some header files in the 
'Plugins' subdir (as of 
rev 209). These are better in 'Headers' (though I am not sure these particular 
files are needed?). 
One of the reason why it is best to only have the plugins in 'Plugins' subdir, 
is that the "Show 
Info" panel in the Finder actually shows the plugins present in this subdir and 
let the user 
manipulate them. When there are spurious files, the Finder also shows them as 
if they were 
plugins. Take a look at the Show Info panel of MacFusion rev 209.

Original issue reported on code.google.com by charles....@gmail.com on 18 May 2007 at 6:43

[GoogleCodeExporter]

Nice to see someone else working on plugins for MacFusion. Your suggestions 
make a
lot of sense, I'm working on implementing this stuff in SVN now.
You are welcome to find me on IM through google chat (same address), if you've 
got
any questions or want updates on this issue.

Michael

Original comment by mgorb...@gmail.com on 20 May 2007 at 8:40

• Changed state: Accepted

[GoogleCodeExporter]

Sorry I only work on a very limited basis on this (extra) project, so I won't 
be of much help except suggesting 
things. I will post more about the plugin when I have time. The plugin works 
fine, and it did not take too long 
to get it to work.

Another aspect that could be improved is to provide a superclass in addition to 
the protocol (and have the 
superclass compy with the protocol), because a lot of the code is actually 
duplicated. In fact, ~80% of the code 
in my Xgrid plug-in (aside from the code for the external xgridfs tool) is 
pasted from your classes. The nice 
benefit of using the BUNDLE_LOADER trick is that it also allows to have the 
superclass linked to at compile 
time without having to create an external framework just for that. The header 
for the superclass would also 
have to be included in the Headers subdir.

Original comment by charles....@gmail.com on 21 May 2007 at 10:53

[GoogleCodeExporter]

Original comment by grahampe...@gmail.com on 17 Jun 2007 at 12:11

• Changed state: Started
• Added labels: Plugin_API, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by grahampe...@gmail.com on 19 Jul 2007 at 9:48

• Added labels: fs_xgrid