

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
8 messages in net.java.dev.jna.usersRe: [jna-users] JNAerator : parses C ...| From | Sent On | Attachments |
|---|---|---|
| Olivier Chafik | Feb 15, 2009 11:51 pm | |
| Nikolas Lotz | Feb 16, 2009 2:31 am | |
| Olivier Chafik | Feb 16, 2009 11:18 am | |
| Stefan Endrullis | Feb 17, 2009 1:47 am | |
| Paul Loy | Feb 17, 2009 1:54 am | |
| Stefan Endrullis | Feb 17, 2009 2:30 am | |
| Timothy Wall | Feb 17, 2009 4:40 am | |
| Olivier Chafik | Feb 23, 2009 5:13 am |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [jna-users] JNAerator : parses C (and Objective-C) and outputs JNA (and Rococoa) interfaces | Actions... |
|---|---|---|
| From: | Olivier Chafik (oliv...@gmail.com) | |
| Date: | Feb 23, 2009 5:13:00 am | |
| List: | net.java.dev.jna.users | |
I tried SWIG quickly like you did, but I stopped because it doesn't parse Objective-C and needs native compilation on each target platform. Besides, using their parse tree for JNA would require either writing tons of C/C++ code inside a modified SWIG binary or build a Java tree out of their output (http://www.swig.org/Doc1.3/SWIGDocumentation.html#Extending_nn8), which is halfway to building a dedicated parser.
Moreover, I was seduced by the kind of object models used in Spoon (http://spoon.gforge.inria.fr/) and Jackpot (http://jackpot.netbeans.org/), with visitors that let you perform arbitrary transformations to the parse tree. That's what I did for JNAerator, and I can transform the parse tree bit by bit until it becomes plain Java (then root.toString() gives me indented Java source with comments). Note that while JNAerator's object model more or less supports C, Objective-C and Java (with bits of C++), the parser is currently completely unable to read Java.
Another option would have been to ask for the xml output of GCC in Objective-C++ mode, but then again, bye bye to pure Java...
As for code generation with speed in mind, I've also been working on some ASM-based bytecode generation to implement JNA libraries interfaces, but it's still too early to say if I'm getting anywhere... (the case of Object arguments would still require a bit of reflection, but indeed I believe we can get rid of most of it, even in the C/JNI code of JNA). Hope to give you some update soon :-)
Best regards
-- Olivier
2009/2/17 Timothy Wall <twal...@dev.java.net>
Has anyone looked into SWIG for this purpose? I did at one time, since at least on the surface it appears that you could write a configuration file describing the transformation(s), but I never had time to follow it through to see if you'd end up having to do a lot more tweaking to get it to work.
Note that once you have a code generator, you don't have to stop at generating the interfaces, but you could go all the way to generating a JNI-like signature that includes hard-coded type information in the arguments, which could bypass most if not all of the reflection.
On Feb 17, 2009, at 4:55 AM, Paul Loy wrote:
Hi Oliver,
this is something I had toyed with doing myself in the past. As Stefan says, people (and I count myself as one) would be interested in improving it.
I like your approach to it. When I was looking into doing it I was going to preprocess and then using ANTLR to parse it! Although mine would have been a bigger hack as I was going to run gcc on a Process to perform the preprocessing. The Anarres C PreProcessor looks like a much more elegant way to do this!
I've been looking at wrapping GTK in Java using JNA for quite some time. I think I'll fire up my mac and see how this baby does on that!
Thanks,
Paul.
On Tue, Feb 17, 2009 at 9:47 AM, Stefan Endrullis <ste...@endrullis.de> wrote: Hi Olivier,
thanks for creating JNAerator. Now that there is an open source platform for this kind of tools I hope more and more people, who also want to map large C libraries, will join and improve the project.
I would suggest to link the project on the JNA website, even if it's an alpha version, but many people could be interested in it and are willing to improve it instead of writing their own perl or sed scripts. :)
Regards, Stefan
Olivier Chafik schrieb:
Hi folks,
Over the past few months I've been working on that famous missing interface generator for JNA. It started with a small and dirty hack with regexes, and became a huge and dirty hack powered by a ANTLR parser and by the Anarres Java C PreProcessor <http://www.anarres.org/projects/jcpp/> (JCPP).
JNAerator (hehe) is still very buggy and has many limitations but I think it might already be useful to JNA users who need to generate large interfaces (it knows about defines, enums, constants, structs, callbacks, converts comments to javadocs, has experimental expressions translation...).
I've written a first post on my blog about it : http://ochafik.free.fr/blog/?p=121 and created a project on Google Code : http://jnaerator.googlecode.com/
I'd be interested in getting feedback on what should be the default generated mappings (right now I'm doing a bit like gluegen : each function that has primitive-friendly arguments gets two methods : one with *ByReference objects and the other with primitive arrays or strings). I'd also need to know more about the preprocessor symbols that are set by the compilers for all of the platforms & architectures supported by JNA, as I only have access to two compilers (Visual Studio Express C++ 2008 & Apple's GCC 4.0, on x86_64), and it would also be great if I could get the possible default paths of system includes on all of these platforms... (the goal is to set things up as simply as possible, but users may still define their include paths and preprocessor symbols by hand).
Finally, I'm still in search for anything that makes C/Objective-C parser explode, even though it already has many known limitations (such as function signatures of functions that return functions, amongst other niceties).
Looking forward to reading from you ! Best Regards
-- Olivier http://ochafik.free.fr/
--------------------------------------------------------------------- To unsubscribe, e-mail: user...@jna.dev.java.net For additional commands, e-mail: user...@jna.dev.java.net
--
--------------------------------------------- Paul Loy pa...@keteracel.com http://www.keteracel.com/paul







