Make it possible to contribute without nix

[tom-a-wagner]

I wanted finally start contributing to get this into shape for a release, and realised that the sys/Gir.toml isn't set up with paths to all the neseccary Gir files, so I pointed it to my dev-containers /usr/share/gir-1.0 dir.

Then I realised the Wp-0.4.gir file contains errors (as do other the other libraries), so I set up a gir-files subproject pointing to https://github.com/gtk-rs/gir-files, and a gir-files-wp directory containing Wp-0.4.gir, as well as a fix.sh shell file to start fixing problems in the Wireplumber Gir file

(tldr: I tried to set up everything the way all the other gir-based rust bindings do.)

Then I finally realised your handling all this in flake.nix instead.

Nix is pretty neat, but also complicated and most people don't use it, and it's not even packaged for fedora. Would you consider setting up the project in line with the other gir rust projects to make it easier to contribute?

[arcnmx]

So, I believe that there are still multiple issues to resolve before the codegen can actually be fully automated - I've been having to run a few manual steps and fixes to the gir output. Packagers, users, and contributors alike are currently expected to use the generated source residing in the repo and ignore gir rather than running the generation externally (which would ideally be a no-op anyway, since the output of that process is committed as source code).

I can certainly work to clean that up and extract some of the scripts from the flake.nix though, and track some of the remaining issues blocking the gir generation. I'll also check if it's out of date and missing newer wp APIs, since it has been a few months since I last ran it.

EDIT: it was already run for wireplumber 0.4.14, so there shouldn't be anything new to generate for wireplumber-sys. If you need to work with the top-level Gir.toml, I'll try to extract some of those scripts for you.

EDIT2: this should mostly be addressed now?

[tom-a-wagner]

Thanks, it works a little better now.

We'll also have to settle on a version of the gir binary. Other Rust gir projects include gir as a subproject which would make clear exactly what version should be used.

For now, I tried to regenerate using the latest gir version, which generates some things differently, so everything should be regenerated together before making changes to the Gir.toml files.

So I tried to regenerate everything, but couldn't generate the sys crate due to patches failing to apply:

patching file src/lib.rs
Hunk #1 FAILED at 3.
1 out of 1 hunk FAILED -- saving rejects to file src/lib.rs.rej
patching file tests/abi.rs
Unreversed patch detected!  Ignore -R? [n] n
Apply anyway? [n] y
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file tests/abi.rs.rej

Unfortunately I haven't quite figured out how to fix those yet.

[tom-a-wagner]

I guess the reason the patches no longer apply is that the dox feature mentioned in the patch doesn't exist anymore with newer gir versions, instead a docsrs cfg is used.

Pulled from a random item:

-    #[cfg(any(feature = "v0_4_11", feature = "dox"))]
-    #[cfg_attr(feature = "dox", doc(cfg(feature = "v0_4_11")))]
+    #[cfg(feature = "v0_4_11")]
+    #[cfg_attr(docsrs, doc(cfg(feature = "v0_4_11")))]

[arcnmx]

We'll also have to settle on a version of the gir binary

From what I understand the gir version should track the glib version, so it is currently pinned to 0.17 but will be updated to 0.18 as part of #26. If you're using newer that would explain why the patches fail.

(if you continue to run into issues with the patches, I'd suggest reading them and then just applying the reverse change manually - it's pretty trivial, just a few lines that need to be added back in to fix the compile)

Other Rust gir projects include gir as a subproject which would make clear exactly what version should be used

I'm not sure how I feel about a binary development tool (and associated gir-files data) that isn't used as part of the build process being a submodule, it's just not a dependency. That seems more like what something that direnv/nix-shell/venv/asdf/conda/etc. would be for. If you need the exact same version, it's currently tracked in flake.lock. It'd probably be easiest to provide a cargo wp install gir command that just runs:

cargo install gir --root ./ci/ --git https://github.com/gtk-rs/gir --branch "$(jq -r .nodes.\"gir-src\".original.ref flake.lock)" --rev "$(jq -r .nodes.\"gir-src\".locked.rev flake.lock)"

Which will plop it right down into ./ci/bin for you.

[tom-a-wagner]

@arcnmx Thanks, should've guessed that the version is tracked in one of the flake files.

Was able to regenerate properly now, with no changes except for the version comments.

Now that it works, I'll start working on some contribututions.