search

AccessKit / accesskit

Accessibility infrastructure for UI toolkits
https://accesskit.dev
BSD 3-Clause "New" or "Revised" License
1.05k stars 53 forks source link

feat: Pre-generate the C header file #439

Closed mwcampbell closed 3 months ago

mwcampbell commented 3 months ago

As we get closer to upstreaming the GTK AccessKit integration, there are two issues with the C bindings that we need to fix:

  1. The dependency on a nightly Rust toolchain to generate the header. Distro packagers will certainly not accept this. So, for now, we commit the generated header file and rely on CI to check it.
  2. The need to handle things like generating a pkg-config file and creating a shared library with the correct version number in its official name (soname), and the appropriate symlinks. cargo-c does these things. I'm adding cargo-c as a second build system, not replacing CMake, since CMake works well enough for embedding the C bindings in projects outside the Linux distro world, especially when using the prebuilt binaries.
DataTriny commented 3 months ago

I haven't looked into the cargo-c part yet. I wonder if Corrosion might be able to help with sonames, I know I read stuff at the time but I can't recall whether it was implemented yet. I'm not a big fan of having a separate path for Linux as CMake should be able to handle this, and we're only making it harder with our deep directory structure. I understand why it is desirable as we frequently push new releases, but this doesn't seem to be a common practice.

mwcampbell commented 3 months ago

I don't think adding cargo-c as a second build option will increase maintenance cost much in the long term. And I'm adding it as an alternative rather than replacing CMake because I don't want to disrupt the solution that's working well enough for the non-distro use case.

Maybe it would be possible to do what I need with CMake, but cargo-c makes it pretty easy. I've already verified that it works in the build system used to build the GNOME OS images and Flatpak runtime.

mwcampbell commented 3 months ago

I backed out the cargo-c part of this PR. I'm not sure yet if cargo-c is what we actually need, particularly for GTK. We might actually need to add Meson instead in order to meet GTK's requirements. But I want to at least get the header file pre-generation merged.