From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhigang Wang Subject: Re: [PATCH] add xl ocaml bindings Date: Tue, 29 Jun 2010 05:58:11 +0800 Message-ID: <4C291AF3.7010203@oracle.com> References: <1277707643-788-1-git-send-email-vincent.hanquez@eu.citrix.com> <1277719149.25867.311.camel@zakaz.uk.xensource.com> <4C2887EC.1050603@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C2887EC.1050603@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Vincent Hanquez Cc: Ian Campbell , Xen Devel List-Id: xen-devel@lists.xenproject.org I did some investigation on python bindings. It seems the best way today is using ctypes. There are a few tools to autogenerate the bindings, but in my mind, the best way is: generate at first time and then make some changes and maintain it manually. I think user readability is most important. And I was thinking xl should written in python. Thanks, Zhigang On 06/28/2010 07:30 PM, Vincent Hanquez wrote: > On 28/06/10 10:59, Ian Campbell wrote: >> Not really a comment on this patch as such but more a related thought... >> How many language bindings do we think there are going to be and how >> much effort do we expect it would be keeping them all (or even just the >> interesting subset) up to date? >> > I'm not sure if you're asking generally in terms of languages or in > terms of bindings. I think from the point of view of bindings, that was > the only thing left that required a binding. in terms of language, I > don't really know if anyone is going to add some python bindings or not. > it depends if xend is going to die, or is going to be ported. > > effort wise, it's hard to answer since it depends on lots of variables. > for example, API stability of libxenlight. > >> Is it worth investing the time up front to define a (simple) IDL and to >> generate the C header and language bindings from that? >> >> Are there any existing IDLs which would meet our needs? >> > Theoretically, yes. pratically there's no IDL that i know of, that > generate anything remotely close to be good or even useful. (it's maybe > no surprise that all the python bindings are not autogenerated either) > > swig seems to generate bindings really close to the C layer which make > it quite annoying since the ml glue code become quick thick and quite > annoying to write (converting back and forth types) and i've never > actually tested the output of swig, and last time i tried camlIDL on a > simple example, it generated a code that would segfault. > > one more thing about generic bindings generator, is that it's hard to > provide nice and clean interfaces. most of the time you stay really > close to the C layer, which defeat the whole point of using a high level > language for the user. > > FYI, I've rewritten a little program to help me generate the bindings > actually, but yet, it's quite painful to get right (and it's not in any > Xen-friendly language either), and in the end i decided to take some of > the output and fix it up by hand. in any case, it's really really far > from having a automatic "./program idl > code" step in the code. > >> the libxl interface from needing to know enough about each language to >> fixup the bindings (or else they may break the build). At least in the >> normal case where the change does not require a change to the IDL then a >> simple regeneration should be enough to update the bindings for the >> change. >> > hopefully in most cases, as long as everything doesn't change too badly, > adding fields is relatively easy even for someone that doesn't know ocaml. >