Writing a GObject-Introspectible Library in Rust in 2023


Something that has piqued my interest recently is being able to use GObject-Introspection as an alternative to raw libffi for writing libraries that can be used from other languages. I was able to successfully get a sample library together in Vala that I could introspect and use from python pretty easily, but since I have been playing with rust recently I have been interested in trying to do the same with Rust.

I read this wonderful blog post but the sample code doesn’t compile anymore. I also didn’t see anything about writing libraries in the gtk-rs-core documentation, just writing applications that use gtk, gio, etc.

Since the rust ↔ GObject interaction has evolved a lot in the past few years I am not sure if fixing the sample code from the blog post is the best way to go or if there is an official way to write a GObject-Introspectible library in rust I can call from python, gjs, etc. I missed. I can go try to find my own way but I would rather not if it is a solved problem :slight_smile:

Thank you for your help as always.

1 Like

I would recommend looking at rdw, which is a library written in Rust but exposing a C API and its corresponding introspection ABI.

I looked into an automatic process for this for a while but never got time to finish it. IMO a macro is not needed but can make some things easier. To generate the gir data would require a very similar process to how it’s done in C.

  1. Parse the library’s Rust source code for all public types
  2. Use attributes/annotations/heuristics to determine which ones are gobject types
  3. Generate a small program to extract metadata from all types and functions
  4. Use the metadata to build a complete mapping from Rust types to C types
  5. Use the mapping to generate an XML file
  6. Use the mapping to generate .h files

This is an oversimplification but, from there the normal gir tooling could be used. AFAIK that RDM library is using a fork of cbindgen that only implements steps 1, 2, 6.

Thanks for the recommendation.

I did a little poking around and it does look like the functionality needed for GObject APIs is not available in the base cbindgen. It seems cbindgen has different “recipes” it follows depending on who it is generating headers for (i.e. cython, c++, c). The rdw maintainer added in GObject functionality, but its obvious I will have to take a closer look at how cbindgen is working to see if g-ir-scanner can just be run against the output of cbindgen or if the GIR XML files are being generated some other way.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.