Best practices for meson wrapped subprojects with patches

Help
1

Hi,

wondering if anyone has recommendations on how to write a nix derivation for a project that is built with meson and that relies on wrapped subprojects with patches.

One approach i have seen so far consists in removing the wrap file, and replacing the corresponding directory (via a symlink) with a fetched package (e.g. from github). That seems to work, but then the project may be missing patches, and a meson.build which are defined under subprojects/packagefiles/..., which meson usually applies when “unwrapping” or processing the .wrap file.

I’m wondering how people handle this. I started to browse the nixpkgs repo, but have yet to find an example that deals with patches and missing meson.build files.

Thanks!

5 Likes
2

+1 for this question,I am actually wondering the same thing.

1 Like
3

+1 for this question as well

I ran into this problem of “no existing proper way to do it”, when packaging the espressif fork of qemu: GitHub - espressif/qemu: Fork of QEMU with Espressif patches. See Wiki for details. as a nur package: nur.repos.c2vi.qemu-espressif.

I just overwrote the src of the derivation from nixpkgs (nixpkgs/pkgs/applications/virtualization/qemu/default.nix at bfb7a882678e518398ce9a31a881538679f6f092 · NixOS/nixpkgs · GitHub), but that one uses the qemu-tarballs (https://download.qemu.org/qemu-8.1.3.tar.xz), which include the subprojects populated with all the patches. My fetchFromGithub of the fork does not include subprojects. (nor do their release tarballs at: Release esp-develop-8.2.0-20240122 · espressif/qemu · GitHub)

so here is my dirty solution of copying subprojects and patches manually: nixos/nur.nix at cdf4a5f369c6303eb0a49249305293fc046d94a2 · c2vi/nixos · GitHub

4

FWIW, I do something similar, but I fetch only the subprojects that are not included in upstream qemu: nix-qemu-espressif/packages/qemu-espressif.nix at 1f2df2aa85529ee136910fbc39f2347ce2bf050f · SFrijters/nix-qemu-espressif · GitHub

5

Why didn’t you add you package to the NUR? I would have just used yours if I had found it there.

Also after searching the nur-combined instead of https://nur.nix-community.org/ i found:

      src = fetchFromGitHub {
        owner = "espressif";
        repo = "qemu";
        rev = "esp-develop-8.2.0-20240122";
        hash = "sha256-Aa4+d5zCIz+hbUj5kGl4AwvApYfgP9C1nPI2Q5vAvEk=";
        nativeBuildInputs = [
          cacert
          git
          meson
        ];
        postFetch = ''
          (
            cd "$out"
            for prj in subprojects/*.wrap; do
              meson subprojects download "$(basename "$prj" .wrap)"
              rm -rf subprojects/$(basename "$prj" .wrap)/.git
            done
          )
        '';
      };

at: nur-combined/repos/nagy/pkgs/by-name/qe/qemu-esp32/package.nix at e9ca76e51b938e6c81028029c33da8ae71da1b03 · nix-community/nur-combined · GitHub

This one is also not part of NUR for some reason.
EDIT: OHHHH, this was committed litearly 17 minutes ago, that explains it xD xD,: qemu-esp32: init at 8.2.0 · nagy/nur-packages@a7b84f8 · GitHub

This postFetch attr of fetchFromGithub is definitely the cleanest way I’ve seen so far. No manual specifying and linking of subprojects needed.

1 Like
6

No good reason, there are so many parts of the nix ecosystem I don’t know much about and NUR is one of them :slight_smile:

There was some recent discussion about this here and I tend to agree that I’d rather fetch the subprojects “myself” in the nix code. But the postFetch stuff is a lot more concise for sure.

7

Thanks for sharing your thoughts, folks! It’s really helpful to hear about your experiences and different strategies for dealing with Meson-wrapped subprojects in Nix. I’ll definitely look into using the postFetch attribute for a cleaner solution in my own projects. Also, I’ll explore adding my packages to the Nix User Repository (NUR) to make them more widely available. Your advice is much appreciated

8

I also maintain a package that needs meson .wrap files.

I used a strategy pretty similar to the one above, though I didn’t use nativeBuildInputs, because I assumed it’s not supported inside fetchers. Nice to know.
Edit: turns out you can’t use nativeBuildInputs if fetchSubmodules is enabled too.