Generate gobject bindings as part of our build process

[mitchellh]

We currently depend on https://github.com/jcollie/ghostty-gobject but there's no reason to have a dependency at all; we can generate all of this as part of our normal build process.

We should probably use the GIR files provided by the system if they're available but I don't want to force more complexity for packagers so if we can fallback to GIR files we provide that'd be good.

This may also fall under the umbrella of preprocessing that shouldn't be happening at all during a packaging process so we may want to consider generating and vendoring this as part of our source tarball build (similar to how C libs e.g. gettext convert their parsers from y to C before source tarball build).

[pluiedev]

The problem is that then the bindings we generate would depend on the versions of the libraries installed on the user's computer, which means that we need to do comptime version checks again to selectively exclude code — we were able to avoid this for a while since if we used symbols in the bindings that were absent from the system libraries, it's a link-time error; if we generate bindings individually then it's a compile-time error which is much more annoying to avoid

[mitchellh]

The problem is that then the bindings we generate would depend on the versions of the libraries installed on the user's computer, which means that we need to do comptime version checks again to selectively exclude code

Is this an argument to bundle our own GIR files then? I'm completely okay with that and throwing them up on deps.files.ghostty.org.

[pluiedev]

I think that's totally fair

[mitchellh]

That's effectively what we're doing now already so I do argue that vendoring (via a deps URL) all the GIR files to start is probably the right initial approach. It doesn't change what's already been happening. If there is a benefit or request (packagers) to support system GIR files then we can entertain that later.

[jcollie]

A couple of notes:

1. The .gir files that are needed to build the GObject bindings are not included in the upstream source tarballs (or git repo). They are built based upon data extracted from comments in the source code. So unless we want to build all of GTK (and related dependencies) we'll need to depend on the installed files from some distro.

2. I've added a process to my ghostty-gobject repo to generate tarballs of all the .gir files that were used to create the GObject bindings. See: https://github.com/jcollie/ghostty-gobject/releases/tag/0.14.0-2025-03-15-20-1

3. One advantage of building the GObject bindings during the Ghostty build process is that version macros (like GTK_VERSION_MAJOR etc) will match those of the development platform, not the platform that the bindings were generated from.

4. If wanted, I'm willing to move the ghostty-gobject repo into the Ghostty GH org which will allow for more people to be able to maintain the project.

[mitchellh]

Okay, I understand what's happening with ghostty-gobject. I see how we could do it all in our build process.

To simplify the scope of this, I think we should store the GIR files in a deps archive we download at least for now. This is basically the same thing we're doing now (since we're downloading the bindings as an archive). It doesn't change the threat model, dependency requirements, etc etc.

I see how you get the GIR paths @jcollie and this is one area I think Nix can make things really easy for us. If you want to extract a nix run command in order to generate the GIR tarball then we can use that to setup our deps (manually -- they don't need to change often I think).

From there, I think we should generate the rest in our build process. I think that'll be fairly straightforward.

[mitchellh]

I hit submit too early. I think the previous comment is good enough for the scope of this issue. If we want to expand to using system-provided GIR files then I think that's a separate scope and also at least for me needs a bit more justification due to the build complexity. For now, packagers have been happy with our approach so I think the tarball of GIR files is easy enough to get going with.

[mitchellh]

Oh okay, I got pretty far, and it is very annoying that translate-gir generates a build.zig file. It'd be much nicer if it emitted source files that used relative imports to read each other then we could create our modules directly from our build.zig. I'll see if we can work around this if not may have to feature request up to zig-gobject.

This isn't the highest priority thing, anyways.