Re: [jna-users] JNAerator : parses C (and Objective-C) and outputs JNA (and Rococoa) interfaces - Timothy Wall - net.java.dev.jna.users

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:	Timothy Wall (twal...@dev.java.net)
Date:	Feb 17, 2009 4:40:53 am
List:	net.java.dev.jna.users

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. :)

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

	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: