Le 3 nov. 06 à 23:55, Jonathan Paisley a écrit :

rb_main.m is in the app which loads the plugin; I have traced the Ruby code, the plugin's Ruby classes are loaded correctly.

In my earlier email, I mentioned the idea of triggering the RubyCocoa initialisation process via the dynamic linker's ability to automatically call init functions (see '-init' argument to ld).

Hopefully that may work.

This sound really complicated to me, and unnatural. I just want Cocoa to work properly and recognise my Ruby principal class.

I'm a bit confused about what's going on. Perhaps you could describe the situation you've got in more detail?

Yes, you are right, I should have been more precise.

I am developing the app *and* the plugin. The plugin is dropped into the app bundle : this can be done through the Finder's inspector, but I just added a file-copy step to my XCode project to put the plugin in the right place when the app is regenerated.

I load plugins like this. For each plugin at 'currPath' :

NSBundle *currPlugin = [NSBundle bundleWithPath:currPath]
if(currPlugin) {
Class currPrincipalClass = [currPlugin principalClass]; // fails for Ruby principal class
id currInstance;
     if(currPrincipalClass) {
      currInstance = [[currPrincipalClass alloc] init]; // create an instance of principal class
// etc.

The main app is using RubyCocoa. As I said previously, for the moment (hack) the main app loads the Ruby code of all the plugins it finds, from the app's rb_main.rb, way long before the plugin is loaded.

The plugin does not use or need to use RubyCocoa (I think ?).
Maybe this is the problem : does [currPlugin principalClass] inspect OC's understanding of the plugin's Info.plist, or does it (possibly) call a plugin-initialisation method which I should override to do some magic RubyCocoa initialisation stuff ?

The plugin is built with a standard XCode "Cocoa bundle" template which includes Ruby code files in Resources.