Skip to content
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

Closed
wants to merge 7 commits into from
Closed

Conversation

fredszaq
Copy link
Contributor

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:

  • new LanguageBackend trait containing functions to write headers and footers in a source file
  • 2 LanguageBackend impls : CLikeLanguageBackend and CythonLanguageBackend
  • the 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)
  • The implementations of Source for the various structs of the ir have been moved to the corresponding backend module as there is now one implementation of Source per LanguageBackend for each relevant ir struct.
  • The implementations of Source for both LanguageBackends 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 for

All tests continue to pass without any modification \o/ (those were quite useful during the refacto)

@yanchith
Copy link

yanchith commented Jul 2, 2023

I am not familiar with the codebase, so I can't really review the patch itself. However, looking at clike.rs and cython.rs, this would give me a solid form to fill out to add the C# backend I need. Looking forward 👍

@fredszaq
Copy link
Contributor Author

@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 ;)

fredszaq added a commit to fredszaq/cbindgen that referenced this pull request Jul 21, 2023
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.
Copy link
Collaborator

@emilio emilio left a 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?

src/bindgen/bindings.rs Outdated Show resolved Hide resolved
src/bindgen/ir/generic_path.rs Outdated Show resolved Hide resolved
src/bindgen/bindings.rs Outdated Show resolved Hide resolved
@emilio
Copy link
Collaborator

emilio commented Aug 25, 2023

Sorry for the lag getting to this btw :/

@fredszaq
Copy link
Contributor Author

Thanks for the review ! I think I tried the write_xxx functions in the language backend trait first but was blocked by something. I cannot remember what though. I'll take a look when I'm back from holidays in september

@fredszaq fredszaq force-pushed the language-backend branch 2 times, most recently from 2ad1a19 to 9d84f34 Compare September 6, 2023 15:21
@fredszaq
Copy link
Contributor Author

fredszaq commented Sep 6, 2023

Hi @emilio ! I just rebased the branch and did the changes you asked, this effectively removes the source trait.

fredszaq added a commit to fredszaq/cbindgen that referenced this pull request Sep 7, 2023
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.
@fredszaq fredszaq requested a review from emilio September 7, 2023 13:03
fredszaq added a commit to fredszaq/cbindgen that referenced this pull request Oct 4, 2023
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.
fredszaq added a commit to fredszaq/cbindgen that referenced this pull request Oct 4, 2023
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.
src/bindgen/bindings.rs Outdated Show resolved Hide resolved
fredszaq added a commit to fredszaq/cbindgen that referenced this pull request Nov 17, 2023
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.
@ZhaoXiangXML
Copy link

Hello, is this MR going to be merged?

@fredszaq
Copy link
Contributor Author

Ping @emilio, I would love to see this merged (and #857) as well. Please tell be what I can do to facilitate this. All the remarks that have been raised till now have been addressed and I'll be pleased to make any other change deemed necessary.

@kang-sw
Copy link

kang-sw commented Jan 30, 2024

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!

fredszaq added a commit to fredszaq/cbindgen that referenced this pull request Feb 5, 2024
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.
fredszaq added a commit to fredszaq/cbindgen that referenced this pull request Mar 12, 2024
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.
@emilio emilio mentioned this pull request Apr 14, 2024
@emilio emilio closed this in #942 Apr 14, 2024
fredszaq added a commit to fredszaq/cbindgen that referenced this pull request Apr 15, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants