There was some talk on IRC last week about desire for Python bindings to LLVM's Object.h C interface. So, I coded up some and you can now find some Python bindings in trunk at bindings/python. Currently, the interfaces for Object.h and Disassembler.h are implemented. I'd like to stress that things are still rough around the edges, so use at your own risk. I intend to smooth things over in the next week or so. I'd really like to fill out the implementation to cover the entirety of the C interface. Since this will require a lot of work (Core.h is *massive*), I wanted to run things by the community before I invest too much time and create something people don't want (I already had to back out the Python binding to EnhancedDisassembly because I didn't realize it was deprecated - oops). Are people interested in more expansive in-tree Python bindings? Specifically, do we want a Python API for the IR primitives like type and value that sit lower than the module APIs? I know there are other Python bindings floating around and from the perspective of the project, one option is to just tell people to go use them. But llvm-py seems to have fallen to the wayside (although I did read a blog post last week where somebody forked it on GitHub and ported it to work with current SVN HEAD). Having in-tree bindings would certainly help prevent bit rot (especially if Python test regressions can mark builds as failed). Finally, I checked in the new bindings with no review (I was given the OK over IRC). If someone would be so kind as to review them, I'd really appreciate the feedback. Also, if I am to commit new features to the Python bindings, does anyone have a problem with continuing to hold off on the review [of new code] until after check-in? I think this would help lower the "time to market" and get more eyes and early testers using the bindings. From my experience with Clang, people aren't exactly lining up to review Python patches, so I fear that new Python features would be sitting in patch purgatory instead of being tested by early adopters. Gregory Szorc gregory.szorc at gmail.com
Hello, Am Donnerstag, 15. März 2012, 21:15:02 schrieb Gregory Szorc:> There was some talk on IRC last week about desire for Python bindings to > LLVM's Object.h C interface. So, I coded up some and you can now find > some Python bindings in trunk at bindings/python. Currently, the > interfaces for Object.h and Disassembler.h are implemented.FYI: I recently startet working on Python3 bindings for LLVM 3 as all bindings I could find were for LLVM 2.x and up to Python 2.6. I used Cython for easier coding and already ported a big part of Core.h including all Type and Value classes. https://www.gitorious.org/python-llvm3> [...] > > Gregory Szorc > gregory.szorc at gmail.comChristoph Grenz
At Fri, 16 Mar 2012 14:12:08 +0100, Christoph Grenz wrote:> > Hello, > > Am Donnerstag, 15. März 2012, 21:15:02 schrieb Gregory Szorc: > > There was some talk on IRC last week about desire for Python bindings to > > LLVM's Object.h C interface. So, I coded up some and you can now find > > some Python bindings in trunk at bindings/python. Currently, the > > interfaces for Object.h and Disassembler.h are implemented. > > > FYI: > > I recently startet working on Python3 bindings for LLVM 3 as all bindings I > could find were for LLVM 2.x and up to Python 2.6. > I used Cython for easier coding and already ported a big part of Core.h > including all Type and Value classes.FYI: I've also been working on new python bindings. My bindings are written using ctypes (just like the in-tree clang/cindex bindings). Most of Core.h is bound, and stuff from ExecutionEngine.h, Analysis, BitReader, BitWriter. The have fairly good test coverage (using nosetests). The ctypes definitions are generated from the header files using the clang python bindings. My local copy also contain a few patches to llvm-c. Everything can be found here: http://people.0x63.nu/~andersg/llvm-python-bindings/ * 0001-Fix-class-hierarchy-indentation-in-LLVM_FOR_EACH_VAL.patch * 0029-Trivial-copy-paste-error-in-LangRef.patch These are just cosmetic stuff that I stumbled upon * 0004-Add-LLVMPrintModule-to-llvm-c.patch Adds a new LLVMPrintModule function which is similar to LLVMDumpModule but dumps to a string instead of stdout. * 0005-Add-LLVMCreateMemoryBufferFromData-to-llvm-c.patch Adds LLVMCreateMemoryBufferFromData function. * 0015-LLVMMessageRef.patch Adds a "typedef char *LLVMMessageRef;". Which may seem useless. But it acts as documentation. All functions that return a string that should be freed with LLVMDisposeMessage are changed to use this type instead. * bindings-python.tar.gz The bindings/python/ directory. There are some hardcoded paths and hacks here and there.
At Fri, 16 Mar 2012 14:12:08 +0100, Christoph Grenz wrote:> > Hello, > > Am Donnerstag, 15. März 2012, 21:15:02 schrieb Gregory Szorc: > > There was some talk on IRC last week about desire for Python bindings to > > LLVM's Object.h C interface. So, I coded up some and you can now find > > some Python bindings in trunk at bindings/python. Currently, the > > interfaces for Object.h and Disassembler.h are implemented. > > > FYI: > > I recently startet working on Python3 bindings for LLVM 3 as all bindings I > could find were for LLVM 2.x and up to Python 2.6. > I used Cython for easier coding and already ported a big part of Core.h > including all Type and Value classes.FYI: I've also been working on new python bindings. My bindings are written using ctypes (just like the in-tree clang/cindex bindings). Most of Core.h is bound, and stuff from ExecutionEngine.h, Analysis, BitReader, BitWriter. The have fairly good test coverage (using nosetests). The ctypes definitions are generated from the header files using the clang python bindings. My local copy also contain a few patches to llvm-c. Everything can be found here: http://people.0x63.nu/~andersg/llvm-python-bindings/ * 0001-Fix-class-hierarchy-indentation-in-LLVM_FOR_EACH_VAL.patch * 0029-Trivial-copy-paste-error-in-LangRef.patch These are just cosmetic stuff that I stumbled upon * 0004-Add-LLVMPrintModule-to-llvm-c.patch Adds a new LLVMPrintModule function which is similar to LLVMDumpModule but dumps to a string instead of stdout. * 0005-Add-LLVMCreateMemoryBufferFromData-to-llvm-c.patch Adds LLVMCreateMemoryBufferFromData function. * 0015-LLVMMessageRef.patch Adds a "typedef char *LLVMMessageRef;". Which may seem useless. But it acts as documentation. All functions that return a string that should be freed with LLVMDisposeMessage are changed to use this type instead. * bindings-python.tar.gz The bindings/python/ directory. There are some hardcoded paths and hacks here and there.