Ok, as you know I'm no expert on this, but...
If our code needs to be able to call Python stuff then I would venture a guess that other programs that use SWIG would perhaps like to do so too. Why not contact the SWIG developers and ask them to support that feature. Others may benefit too!
It's obviously already possible using the work-arounds you mention, so presumably it wouldn't require that much work on their end - they just need to "officially" support the relevant behaviour and ensure that they don't break compatibility in future versions. Unless it directly conflicts with some other plan of theirs I doubt this should be a problem.
And if for some reason they can't do that then at least they can consider our required behaviour a feature request and work out some clean way to implement it in future versions.
Just an idea!
- James
On Apr 23, 2005, at 10:03, Kai Sterker wrote:
On 4/22/05, Andrew Phillips <[EMAIL PROTECTED]> wrote:
It may be a question without an answer, but are there any clues as to why SWIG keeps breaking the code that is dependent on it?
One answer might be that we use SWIG in a way it was not supposed to be used. Specifically, we're not only calling our code from Python (that is what SWIG is for), but also call Python from our code. For latter, we need to access SWIG internals and if they change, our code gets broken.
This time, all functions of the SWIG runtime library have been made static, so we can no longer access them from our code. The workaround for both v0.3.4 and v0.4 is to move the methods that call SWIG internals into the SWIG wrapper, where they have access to the static methods. That did not cause any harm in v0.3.4 where we only have one Python module which is also statically linked. Therefore, it keeps working with older versions of SWIG. In v0.4, where we have multiple, dynamically linked Python modules, we can't continue using the old, non-static SWIG runtime library. Otherwise we'd get duplicate symbols when linking.
I do however hope that there won't be any problems with the next few versions of SWIG ;-).
Kai
_______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel
-- Personal site: http://cirrus.twiddles.com/
_______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel