[LLVMdev] Improving OCaml bindings
Sean Silva
chisophugis at gmail.com
Sat Nov 2 22:22:20 PDT 2013
On Sat, Nov 2, 2013 at 9:04 PM, Peter Zotov <whitequark at whitequark.org>wrote:
> Hello folks.
>
> I'm very interested in improving LLVM's OCaml bindings. I have
> several nontrivial patches sitting on llvm-commits for several
> weeks, and so far there's been little interest in them.
>
> Could someone with a good understanding of OCaml please take
> a look at these?
>
> 1) http://llvm-reviews.chandlerc.com/D1925
>
> Every other function in OCaml bindings accepts context
> explicitly, would it be a legitimate change to make existing
> functions accept it as well? This would break the API.
>
I don't really have a good idea of who uses these OCaml bindings API's. A
good first step is probably to map out the landscape of the users of the
API. Maybe browse research papers? I wouldn't expect to see many OCaml
programs "in production" that depend on this API. Also, I'm not sure if we
have a stated backwards compatibility policy for this API. Ultimately you
probably just want to talk with all the API users you can scrape together.
-- Sean Silva
>
> 2) http://llvm-reviews.chandlerc.com/D1926
>
> I'd like to add garbage collection support to the API
> wherever safe, that's at least DataLayout.t and llmemorybuffer.
> This removes the need for .dispose. I could remove it and break
> the API or print a warning at runtime.
>
> 3) http://llvm-reviews.chandlerc.com/D1927
>
> In order to allow code generation from OCaml, I need to build
> a stub library per configured target. I'm not sure how to
> integrate it with LLVM's build system; my current solution seems
> very ad-hoc.
>
> I will update the patch to use Dynlink interface (this is the
> textbook use case for Dynlink), but conceptually this doesn't
> change the problem of interfacing with build system.
>
> --
> WBR, Peter Zotov.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131103/cf4320c6/attachment.html>
More information about the llvm-dev
mailing list