Re: [Swig-devel] Languages as a Plugin

[William S F. <ws...@fu...>]

I think if you look for the -plugin option in main() in swigmain.cxx, 
you can do the dlopen there if specified. The plugin should provide the 
factory method which can be added to the modules[] table (via calls to 
dlsym). So make the changes in main() such that before the call to 
SWIG_main(), the shared object has been loaded and the plugin target 
language has been instantiated like a normal target language.

I wouldn't bother with -pluginlang, this info can be obtained using 
dlsym and a call into the shared object, a new mandatory global method 
such as:

extern "C" const char * swig_plugin_lang(void) { return "xyzlang"; }

The other global mandatory method will be the factory function:

extern "C" Language *swig_plugin(void) {
   return new XYZLANG();
}

Calls to both these functions will provide the missing swig_module info.

One thing to look out for in the implementation is to make sure -help 
works for the plugin if -help is specified before -plugin.

William

On 07/03/11 22:52, The Carrolls wrote:
>
> The only problem I can see with that, is that the factory method doesn't
> get enough information to determine what library to load and what
> Language subclass to load from the library. The way it is now, the
> factory function doesn't take any parameters. The earliest point I get
> all of that information, as of now anyway, (I think) is in the "main"
> method of the Language subclass. So that's why it's at that point I
> (currently) load the library and instantiate the actual Language plugin.
>
> Unless I missed something ... which is highly likely. :)
>
> On 03/07/11 14:51, William S Fulton wrote:
>> Hi Jim
>>
>> I think we have our wires crossed or something! What I was wondering
>> is why not have a more simple approach along the lines of:
>>
>> The plugin language class derives from Language and is implemented in
>> the compiled .so extensioun and loaded using dlopen as you have done.
>> But instead of adding in the SWIG PLUGIN class which contains a
>> pointer to instance of said new Language derived class, why not simply
>> let the factory function return the Language* and use that directly
>> like a non-plugin language. I can't see how this will require making
>> additional changes to core other than what you've done in
>> swigmain.cxx. Making changes to the SWIG core to enable plugins is no
>> problem at all. In fact if the whole PLUGIN class was removed and the
>> real plugin was used directly, the workarounds for Language::this_
>> wouldn't be needed. I think ;) Maybe I've overlooked something, in
>> which case I need enlightening.
>>
>> William
>>
>
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
>
>
>
> _______________________________________________
> Swig-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-devel