-
Notifications
You must be signed in to change notification settings - Fork 314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce language backend #853
Conversation
230574e
to
96cea22
Compare
I am not familiar with the codebase, so I can't really review the patch itself. However, looking at |
@emilio Did you have time to take a look ? I'm planning to work on the java-jna backend this week, would be nice to have a confirmation we want to go in this direction ;) |
This builds on mozilla#853 and adds a new language backend capable of generating java bindings. The generated bindings use [JNA](https://github.com/java-native-access/jna) (I used the last version 5.13.0 while developping but this will probably work with earlier ones as well) Most of the new code lives in `bindgen/language_backend/java_jna.rs` and is pretty straightfowards generation as most on the complicated things were done in the previous refactoring. The test suite has been updated to generate and compile the bindings for java when running. On nice thing gained with this is the possibilibty to put a configuration file specific to a language alongside the stardard one and the test will take this one instead of the default one if it exists (quite a few test use the `header` config to add some more code inside the generated bindings, C or preprocessor code doesn't work well in a java source file :P) All tests are green, but that doesn't mean all the generated bindings are correct, some cases may fail at runtime as I didn't test all cases in a real program. I did however generate and use the bindings on a non trivial lib I'm developping and they worked as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks generally reasonable, but I think if instead of relying on Source<LB> for T
being implemented we had stuff like:
trait LanguageBackend {
fn write_enum<W: Write>(&self, enum: &Enum, out: &mut SourceWriter<W>);
fn ...;
}
etc, then all the generic soup goes away, right?
Sorry for the lag getting to this btw :/ |
Thanks for the review ! I think I tried the |
2ad1a19
to
9d84f34
Compare
Hi @emilio ! I just rebased the branch and did the changes you asked, this effectively removes the source trait. |
9d84f34
to
314c47d
Compare
This builds on mozilla#853 and adds a new language backend capable of generating java bindings. The generated bindings use [JNA](https://github.com/java-native-access/jna) (I used the last version 5.13.0 while developping but this will probably work with earlier ones as well) Most of the new code lives in `bindgen/language_backend/java_jna.rs` and is pretty straightfowards generation as most on the complicated things were done in the previous refactoring. The test suite has been updated to generate and compile the bindings for java when running. On nice thing gained with this is the possibilibty to put a configuration file specific to a language alongside the stardard one and the test will take this one instead of the default one if it exists (quite a few test use the `header` config to add some more code inside the generated bindings, C or preprocessor code doesn't work well in a java source file :P) All tests are green, but that doesn't mean all the generated bindings are correct, some cases may fail at runtime as I didn't test all cases in a real program. I did however generate and use the bindings on a non trivial lib I'm developping and they worked as expected.
314c47d
to
e3da696
Compare
This builds on mozilla#853 and adds a new language backend capable of generating java bindings. The generated bindings use [JNA](https://github.com/java-native-access/jna) (I used the last version 5.13.0 while developping but this will probably work with earlier ones as well) Most of the new code lives in `bindgen/language_backend/java_jna.rs` and is pretty straightfowards generation as most on the complicated things were done in the previous refactoring. The test suite has been updated to generate and compile the bindings for java when running. On nice thing gained with this is the possibilibty to put a configuration file specific to a language alongside the stardard one and the test will take this one instead of the default one if it exists (quite a few test use the `header` config to add some more code inside the generated bindings, C or preprocessor code doesn't work well in a java source file :P) All tests are green, but that doesn't mean all the generated bindings are correct, some cases may fail at runtime as I didn't test all cases in a real program. I did however generate and use the bindings on a non trivial lib I'm developping and they worked as expected.
This builds on mozilla#853 and adds a new language backend capable of generating java bindings. The generated bindings use [JNA](https://github.com/java-native-access/jna) (I used the last version 5.13.0 while developping but this will probably work with earlier ones as well) Most of the new code lives in `bindgen/language_backend/java_jna.rs` and is pretty straightfowards generation as most on the complicated things were done in the previous refactoring. The test suite has been updated to generate and compile the bindings for java when running. On nice thing gained with this is the possibilibty to put a configuration file specific to a language alongside the stardard one and the test will take this one instead of the default one if it exists (quite a few test use the `header` config to add some more code inside the generated bindings, C or preprocessor code doesn't work well in a java source file :P) All tests are green, but that doesn't mean all the generated bindings are correct, some cases may fail at runtime as I didn't test all cases in a real program. I did however generate and use the bindings on a non trivial lib I'm developping and they worked as expected.
e3da696
to
d550cf7
Compare
This builds on mozilla#853 and adds a new language backend capable of generating java bindings. The generated bindings use [JNA](https://github.com/java-native-access/jna) (I used the last version 5.13.0 while developping but this will probably work with earlier ones as well) Most of the new code lives in `bindgen/language_backend/java_jna.rs` and is pretty straightfowards generation as most on the complicated things were done in the previous refactoring. The test suite has been updated to generate and compile the bindings for java when running. On nice thing gained with this is the possibilibty to put a configuration file specific to a language alongside the stardard one and the test will take this one instead of the default one if it exists (quite a few test use the `header` config to add some more code inside the generated bindings, C or preprocessor code doesn't work well in a java source file :P) All tests are green, but that doesn't mean all the generated bindings are correct, some cases may fail at runtime as I didn't test all cases in a real program. I did however generate and use the bindings on a non trivial lib I'm developping and they worked as expected.
Hello, is this MR going to be merged? |
Oh Wow, this was exactly what I was looking for and trying to implement on my own from this night. God thanks I tried searching 'dynamic' on issue list and found this. Great appreciation for your effort and wish it'd be merged onto mainstream as soon as possible, thanks! |
This builds on mozilla#853 and adds a new language backend capable of generating java bindings. The generated bindings use [JNA](https://github.com/java-native-access/jna) (I used the last version 5.13.0 while developping but this will probably work with earlier ones as well) Most of the new code lives in `bindgen/language_backend/java_jna.rs` and is pretty straightfowards generation as most on the complicated things were done in the previous refactoring. The test suite has been updated to generate and compile the bindings for java when running. On nice thing gained with this is the possibilibty to put a configuration file specific to a language alongside the stardard one and the test will take this one instead of the default one if it exists (quite a few test use the `header` config to add some more code inside the generated bindings, C or preprocessor code doesn't work well in a java source file :P) All tests are green, but that doesn't mean all the generated bindings are correct, some cases may fail at runtime as I didn't test all cases in a real program. I did however generate and use the bindings on a non trivial lib I'm developping and they worked as expected.
fd5497f
to
c531e42
Compare
This builds on mozilla#853 and adds a new language backend capable of generating java bindings. The generated bindings use [JNA](https://github.com/java-native-access/jna) (I used the last version 5.13.0 while developping but this will probably work with earlier ones as well) Most of the new code lives in `bindgen/language_backend/java_jna.rs` and is pretty straightfowards generation as most on the complicated things were done in the previous refactoring. The test suite has been updated to generate and compile the bindings for java when running. On nice thing gained with this is the possibilibty to put a configuration file specific to a language alongside the stardard one and the test will take this one instead of the default one if it exists (quite a few test use the `header` config to add some more code inside the generated bindings, C or preprocessor code doesn't work well in a java source file :P) All tests are green, but that doesn't mean all the generated bindings are correct, some cases may fail at runtime as I didn't test all cases in a real program. I did however generate and use the bindings on a non trivial lib I'm developping and they worked as expected.
This builds on mozilla#853 and adds a new language backend capable of generating java bindings. The generated bindings use [JNA](https://github.com/java-native-access/jna) (I used the last version 5.13.0 while developping but this will probably work with earlier ones as well) Most of the new code lives in `bindgen/language_backend/java_jna.rs` and is pretty straightfowards generation as most on the complicated things were done in the previous refactoring. The test suite has been updated to generate and compile the bindings for java when running. On nice thing gained with this is the possibilibty to put a configuration file specific to a language alongside the stardard one and the test will take this one instead of the default one if it exists (quite a few test use the `header` config to add some more code inside the generated bindings, C or preprocessor code doesn't work well in a java source file :P) All tests are green, but that doesn't mean all the generated bindings are correct, some cases may fail at runtime as I didn't test all cases in a real program. I did however generate and use the bindings on a non trivial lib I'm developping and they worked as expected.
This builds on mozilla#853 and adds a new language backend capable of generating java bindings. The generated bindings use [JNA](https://github.com/java-native-access/jna) (I used the last version 5.13.0 while developping but this will probably work with earlier ones as well) Most of the new code lives in `bindgen/language_backend/java_jna.rs` and is pretty straightfowards generation as most on the complicated things were done in the previous refactoring. The test suite has been updated to generate and compile the bindings for java when running. On nice thing gained with this is the possibilibty to put a configuration file specific to a language alongside the stardard one and the test will take this one instead of the default one if it exists (quite a few test use the `header` config to add some more code inside the generated bindings, C or preprocessor code doesn't work well in a java source file :P) All tests are green, but that doesn't mean all the generated bindings are correct, some cases may fail at runtime as I didn't test all cases in a real program. I did however generate and use the bindings on a non trivial lib I'm developping and they worked as expected.
As discussed in #846 this introduces the notion of language backend in order to facilitate the addition of new supported languages to cbindgen
Notable changes:
LanguageBackend
trait containing functions to write headers and footers in a source fileLanguageBackend
impls :CLikeLanguageBackend
andCythonLanguageBackend
Source
trait is now generic on a LanguageBackend and gets the language backend instead of a config as an argument ( both backend impls, end up wrapping a config)Source
for the various structs of their
have been moved to the corresponding backend module as there is now one implementation ofSource
perLanguageBackend
for each relevantir
struct.Source
for bothLanguageBackend
s come from the existing impls and have been cleaned to contain only the parts relevant to the language of the Backend for which the impl is forAll tests continue to pass without any modification \o/ (those were quite useful during the refacto)