From: techtonik-2 <tec...@gm...> - 2008-09-26 11:53:39
|
It is no uncommon for C libraries to prefix their functions with library names. For example wxWindows names are all prefixed with "wx", Neon library functions with "ne_" etc. Wrapping them into a Python module with SWIG adds additional module prefix making final API rather ugly - like SetFont(wx.wxFont(14, wx.wxSWISS, wx.wxNORMAL, wx.wxBOLD, ... ))) Renaming all functions by hand to strip this wx prefix from C names is not very intelligent. Of course, there are undocumented encoders for %rename function [1] Among them is rxspencer that can do the task, but it doesn't work on windows. Either because it was not ported or because it was not compiled in. The strange thing that there is no warning, although it definitely affects code generation. wxPython folks maintain their own wxpy encoder as patch to SWIG in their SVN tree to strip wx prefix from wxNames [2], but some general prefix strip encoder would be useful for all C users. I made a patch with such encoder and would be grateful if somebody could find a time to review it at [3] Speaking about Python and method renames - there is minor bug with docstring generator that instead of original C names for classes and structs substitutes renamed. The patch against SVN is at [4] [1] http://article.gmane.org/gmane.comp.programming.swig/11466/match=rename How to strip off enum prefix? [2] http://trac.wxwidgets.org/browser/wxPython/branches/WX_2_8_BRANCH/SWIG/README.txt [3] http://sourceforge.net/tracker/index.php?func=detail&aid=2130016&group_id=1645&atid=301645 [4] http://sourceforge.net/tracker/index.php?func=detail&aid=2128249&group_id=1645&atid=301645 -- View this message in context: http://www.nabble.com/Strip-off-prefix-from-C-names-for-Python-module-tp19686794p19686794.html Sent from the swig-user mailing list archive at Nabble.com. |
From: William S F. <ws...@fu...> - 2008-11-01 23:18:19
|
techtonik-2 wrote: > It is no uncommon for C libraries to prefix their functions with library > names. For example wxWindows names are all prefixed with "wx", Neon library > functions with "ne_" etc. Wrapping them into a Python module with SWIG adds > additional module prefix making final API rather ugly - like > SetFont(wx.wxFont(14, wx.wxSWISS, wx.wxNORMAL, wx.wxBOLD, ... ))) > > Renaming all functions by hand to strip this wx prefix from C names is not > very intelligent. Of course, there are undocumented encoders for %rename > function [1] Among them is rxspencer that can do the task, but it doesn't > work on windows. Either because it was not ported or because it was not > compiled in. The strange thing that there is no warning, although it > definitely affects code generation. wxPython folks maintain their own wxpy > encoder as patch to SWIG in their SVN tree to strip wx prefix from wxNames > [2], but some general prefix strip encoder would be useful for all C users. > I made a patch with such encoder and would be grateful if somebody could > find a time to review it at [3] > > Speaking about Python and method renames - there is minor bug with docstring > generator that instead of original C names for classes and structs > substitutes renamed. The patch against SVN is at [4] > > > [1] http://article.gmane.org/gmane.comp.programming.swig/11466/match=rename > How to strip off enum prefix? > [2] > http://trac.wxwidgets.org/browser/wxPython/branches/WX_2_8_BRANCH/SWIG/README.txt > [3] > http://sourceforge.net/tracker/index.php?func=detail&aid=2130016&group_id=1645&atid=301645 > [4] > http://sourceforge.net/tracker/index.php?func=detail&aid=2128249&group_id=1645&atid=301645 > Thanks I've added your encoder and bugfix. Although a generic regular expression encoder would be better, it would probably take too much effort at this point to get it done and this strip encoder meets a common request and is a lot faster than using an external tool such as sed with the command encoder. I don't know about wxspencer on Windows, someone would need to find the time to debug it. You are probably the first to test it on Windows. William |
From: Nitro <ni...@dr...> - 2008-11-02 17:00:25
|
> Thanks I've added your encoder and bugfix. Although a generic regular > expression encoder would be better, it would probably take too much > effort at this point to get it done and this strip encoder meets a > common request and is a lot faster than using an external tool such as > sed with the command encoder. > > I don't know about wxspencer on Windows, someone would need to find the > time to debug it. You are probably the first to test it on Windows. I'd also test a compiled win version with rxspencer. The strip encoder seems nice, but it won't do everything for me (e.g. "DCVector" needs to be renamed to "Vector" and "IDCRenderer" to "IRenderer" in my case. I've looked at the strip-encoder patch a few days ago, but it can't deal with the second case if I read the code right). It seems rxspencer would be capable of doing what I need. Right now I am using the xml two-pass approach (first pass generate xml, generate .i files with %renames from the xml and then run swig again with the %rename .i included). This approach really slows things down (swig generates several xml files, each several 100 MBs which needs to be parsed). So if there's a win rxspencer build, I'd gladly test it. -Matthias |
From: anatoly t. <tec...@gm...> - 2008-11-03 08:31:18
|
On Sun, Nov 2, 2008 at 1:18 AM, William S Fulton <ws...@fu...> wrote: > > Thanks I've added your encoder and bugfix. Nice! We could remove more custom patches from wxWindows when 1337 V3R510N goes out. =) > Although a generic regular > expression encoder would be better, it would probably take too much effort > at this point to get it done and this strip encoder meets a common request > and is a lot faster than using an external tool such as sed with the command > encoder. > > I don't know about wxspencer on Windows, someone would need to find the time > to debug it. You are probably the first to test it on Windows. rxspencer is not distributed with SWIG sources and I do not know if it was ported to windows compilers. For now a simple warning when unknown encoder is used (in case it was not compiled-in) would be just great. -- --anatoly t. |