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

Use girepository to invoke library functions #20

Open
pekim opened this issue Feb 13, 2020 · 1 comment
Open

Use girepository to invoke library functions #20

pekim opened this issue Feb 13, 2020 · 1 comment

Comments

@pekim
Copy link
Owner

pekim commented Feb 13, 2020

The current generation code is unfortunately an unmaintainable mess. I had no idea when I started writing it how many parameter types and variations there were. Nor did I understand how many of the permutations would need to be handled. As a result I can't see a way to migrate the current code to a better place. I'd normally prefer to iteratively refactor code to improve it, but in this case I don't think that it's practical.

The generated code is also problematic in that it's very slow to build. This is mostly because of the extensive use of cgo. It's in every wrapping function, and there are many generated C functions for callbacks. This makes development of gobbi painful, with continuous rounds of code generation and slow builds.

It's difficult to move forward with the code as it is. Issues #16 and #17 are examples of cases where I struggle to work with the existing generation code.

I am looking at re-writing to use girepository for invocation of library functions.

Pros

  • the generated functions that wrap library functions will be become simpler, and will not contain any cgo code
  • the code that generates the wrapper functions will be simpler
  • all cgo code will be in one or two internal packages
    • all of the complexity of the multitude of parameter types and variations will be in here
    • all of the marshalling of parameters between Go types and C types will be in here
    • all of code dealing with transfer of ownership will be in here
    • much of the code will be amenable to unit testing
  • building will be much quicker

Cons

  • there will be a small overhead on function calls
  • unavailabilty of a library function (for example running an application on a system with older than required version of a library) will not be detected until it is first called

Initial work is proving promising. It will be at least several more weeks before it's in a reasonably useable state.

@rythmkraze
Copy link

Are you talking about invoking library functions from typelib files via GIRepository Manager?

If so then, here is a conversation that I had with the Gtk-Rust team
typelib-vs-xml

To conclude, gir-xml files are more complete compared to typelibs.

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

No branches or pull requests

2 participants