[LLVMdev] Python-LLVM bindings updated

[Reid Spencer]

On Mon, 2005-05-23 at 22:18 +0300, Jarno Seppänen wrote:
> Hi,
> 
> some discussion below.
> 
> Reid wrote:
> 
> > 3. Fix your Makefile to build a shared library properly. You have set
> >    TOOLNAME which is for building an executable tool not a shared
> >    library. You need to set LIBRARYNAME=..., not TOOLNAME=...
> 
> I remember having failed to build a functioning Python extension module with
> LIBRARYNAME and SHARED_LIBRARY flags.  Anyway, I cannot remember the details
> now so will try again.

Okay. Let me know if you run into any further challenges. This should be
pretty straight forward.

> 
> > 4. Fix the name of your project. It currently builds "llvm.so" which
> >    is not correct by our naming standards. It should result to something
> >    like "libLLVMpy.so" which will be obtained if you set LIBRARYNAME
> >    to "LLVMpy"
> 
> I'd like to challenge the usefulness of the naming standard here.  I see its
> value in case of system-wide C/C++ libraries (going to /usr/lib/*), but the
> Python modules go into a Python-specific directory
> (/usr/lib/python2.4/site-packages/*), so the name must be unique within
> Python extensions only.

Okay, that makes sense. However, you will have bypass the LLVM Makefile
system to do this. I.e. if you use LIBRARYNAME and SHARED_LIBRARY
keywords in your makefile then the name *must* follow our standards
because it *will* get installed to a place where naming conflicts must
be avoided. So, you need to, at the very least, override the rules for
installing llvm.so into the python packages directory. Your
configuration script should also automate the finding of the python
packages directory and also have a --with-python-packages=... option so
the user can override where these files are placed. Let me know if you
need help with setting that up.

> 
> > 5. Consider waiting for or modifying this python interface latter to
> >    either directly use the (forthcoming) C interface or design the
> >    interface to have a similar structure and naming convention.
> 
> The Python interface represents the C++ interface, so I don't understand the
> motivation to use C in the middle?  In my view the Python and C bindings are
> independent of each other.

Okay, my mistake .. guess I didn't look at the patch closely enough. If
you're creating a 1-to-1 mappings between the LLVM core IR classes
(Module, Function, BasicBlock, Instruction, etc), then you're doing the
right thing and should ignore the C interface. 
> 
> > Once you've got the above accomplished, we can create a repository for
> > the python interface and (with Oversight Group approval) give you cvs
> > write access to it. That will allow you to make changes and maintain the
> > python interface as LLVM grows without significant difficulty or burden.
> 
> OK, so I'll get back when I have news about the directory and Makefile
> restructuring. 

Great! We look forward to adding this to the llvm repository. I'm sure
others will find it very useful to start programming with LLVM via
Python!

One final note: please be aware that our current policy for submissions
such as this is that you must acknowledge (an email is fine) assignment
of copyright to the University of Illinois at Urbana Champaign and that
the code is licensed under the U of I license. For details, see
http://llvm.cs.uiuc.edu/releases/1.5/LICENSE.TXT. The license is OSI
approved and similar to a 3-clause BSD license. I.e., it basically says
anyone can use the software as long as they retain the copyright notice,
reproduce that notice it in binaries, and don't use anyone's name in
conjunction with a product. 

Regardless of copyright and license, your submission will always be
attributed to you in our CREDITS.TXT file and elsewhere.

Best Regards,

Reid.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050523/50b91fe3/attachment.sig>