From: William S F. <ws...@fu...> - 2011-03-07 07:24:42
|
Yes this sounds interesting and we can incorporate this into SWIG. I've a question about the implementation. Why have you chosen to use the PLUGIN proxy class instead of just using the target plugin class directly instead? Both approaches require deriving from Language and conforming to the public functions in the Language class and require the same compiler and memory allocator. One other thing I feel compelled to point out and and make sure is understood and that is the implementation of the SWIG plugin must meet the GPLv3 license requirements. William On 05/03/11 13:54, The Carrolls wrote: > > If nobody wants this, I'd rather know that, than waste my time. Negative > feedback is better than none. > > If it matters to anyone I'm a developer on XBMC where we'd really like > to use this. > > Thanks > Jim Carroll > > On 03/01/11 09:14, The Carrolls wrote: >> If you guys wanted to take a look, attached is a patch to the latest SVN. >> >> You need to run configure like this: >> >> ./configure LDFLAGS=-rdynamic >> >> So far it only works on Linux (and, I'm assuming, other dlopen based >> systems) but I don't think it will be difficult to make it work on >> Windows. I'll do that next if you guys are interested. >> >> On 03/01/11 07:20, The Carrolls wrote: >>> Over on the users list I had asked if it would be worth making the >>> generators for new languages plugins to the swig core application. The >>> reason being that I'm considering using swig for a custom code >>> generator but right now in order to add a language you need to modify >>> the main program. >>> >>> It was actually surprisingly easy to do on linux (and I don't think it >>> will be difficult to make work on Windows). I currently have it >>> working like this: >>> >>> swig [options] -plugin path/to/sharedLibrary -language languageName >>> interface.i >>> >>> The '-plugin' is actually a native language (class PLUGIN : public >>> Language) whose sole job it is to read the path to the shared library, >>> and the name of the language, load the shared library in the >>> PLUGIN::main, call the "swig_[languageName]" Language factory >>> function, and then proxy all of the calls from the core. >>> >>> For an initial test I removed python from the core and ran it as a >>> plugin (I compiled Source/Modules/python.cxx into a shared library). >>> >>> I did this without changing a single line of code in the core >>> application (other than the minimum required to add a new language >>> module). >>> >>> There are only two minor problems I ran across. I had to hack around >>> the singleton Language::this_ (but I did it without changing any code >>> in the core), and I cannot proxy the single virtual protected method >>> in Langauge (which isn't overloaded in Python anyway). >>> >>> Fixing these two things would require minimal changes to the core >>> application. >>> >>> Is this something you guys are interested in? >>> >>> Jim >>> >>> >>> ------------------------------------------------------------------------------ >>> Free Software Download: Index, Search& Analyze Logs and other IT data in >>> Real-Time with Splunk. Collect, index and harness all the fast moving IT data >>> generated by your applications, servers and devices whether physical, virtual >>> or in the cloud. Deliver compliance at lower cost and gain new business >>> insights.http://p.sf.net/sfu/splunk-dev2dev >>> >>> >>> _______________________________________________ >>> Swig-devel mailing list >>> Swi...@li... >>> https://lists.sourceforge.net/lists/listinfo/swig-devel >> > > ------------------------------------------------------------------------------ > 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 > |