Skip to content

Create generator integration tests and fix generation issues #70

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

Merged
merged 70 commits into from
Aug 18, 2023

Conversation

ylatuya
Copy link
Collaborator

@ylatuya ylatuya commented Jun 29, 2022

The bindings generator does already a good job but it still has issues in several areas:

  1. Generated code for some use cases does not compile
  2. Generated code compiles correctly but fails at runtime
  3. There are some memory issues with Opaque's
  4. Generator uses the GAPI format instead of generating code directly from GIR files

The goal is to create a proper test suite with integration and unit tests that will help us fix all of the binding generation issues.

This merge request focuses in creating the initial scaffolding for the test suite and attack the first problem of the generator: all the generated code must compile correctly.

The test suite will use the Regress library from gobject-introspection since it provides a broad coverage of all possible uses cases: https://gitlab.gnome.org/GNOME/gobject-introspection/-/tree/main/tests/scanner

The Regress-1.0.gir is processed with bindinate to generate the GAPI xml that is feed into the code generator.

The test suite will start with 2 integration tests:

  • A tests that generates the bindings of the Regress API and validates the number of methods, objects, signals, etc... created.
  • A tests that compiles the generated code and validates the number or errors and warning during the compilation.

Current Status

With this merge request we have gone from:

  1. Not being able to generate any code due to exceptions in the generator
  2. Generated code does not compile with 450 errors and 42 warnings
  3. Create unit tests using the Regress library

To:

  1. Having all code generated and compiling correctly without errors
  2. Fixed several bugs related to array parameters
  3. Have a proper testing infrastructure to work with ease

Next Steps

  1. Create unit test using the Regress library
  2. Fix memory issues with Opaque's
  3. Add support for generating the bindings directly from GIR's

@ylatuya ylatuya force-pushed the unit_tests branch 8 times, most recently from 19016eb to d771bb6 Compare June 30, 2022 15:29
@ylatuya ylatuya force-pushed the unit_tests branch 10 times, most recently from da382b6 to 7874486 Compare July 27, 2022 08:01
@ylatuya
Copy link
Collaborator Author

ylatuya commented Jul 27, 2022

I am having issues with the checks not being triggered :(

ylatuya added 6 commits July 31, 2023 11:23
This simplifies the generated code using the GLib.Marshaller
helpers with a new IGeneratable for array strings.
It fixes a segfault that was using the mearshaller string free helper
instead of the array one.
It fixes a leak of `in` string arrays.

Only treat count paramaters that are annotated as such

This prevent all parameters starting with n_ to be treated
like array count parameters and only those that are annotated
as such

Fix method with single array length param for several arrays
ylatuya added 6 commits July 31, 2023 12:41
Source: https://github.com/GLibSharp/bindinator
Commit: 60c72b6601b4372af5d5c7775cda906cdbce2cb4

bindinator is a very simple project that is only used by GtkSharp
and having it a subproject makes the maintenance harder and it's
not possible to use it with subprojects due to a cyclic dependency:
gtk-sharp -> bindinator -> gtk-sharp
Use the correct path separator on Windows to split
GI_TYPELIB_PATH dirs
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.

1 participant