wasmtime: add enableShared/enableStatic & shell completions

[nekowinston]

The follow-up as discussed in #438391. @ereslibre
With added shell completions for the binary. 🙂

Looking at the use case I mentioned, this takes the size down to
NAR Size: 31.58 MiB | Closure Size: 72.6 MiB | Added Size: 31.58 MiB
when included with most things, since gcc and glibc are usually already included somewhere else.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[nekowinston]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 440501
Commit: 162020f198695e0d2c5b14e28175388580157c2f

---

x86_64-linux

✅ 2 packages built:

• wasmtime
• wasmtime.dev

[ereslibre]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 440501
Commit: 162020f198695e0d2c5b14e28175388580157c2f

---

x86_64-linux

✅ 2 packages built:

• wasmtime
• wasmtime.dev

[ereslibre]

Thank you @nekowinston!

Since we are optimizing, I'm wondering if it would make sense to add an option to skip wasmtime-cli, if a project only needs the C API.

[ereslibre]

Do you know if there's a difference between those two in practice? (Does wasmtime completion do anything other than cat the completion files?).

I'm asking because if not, we could simplify to just run the second option in both cases, when stdenv.buildPlatform.canExecute and when it cannot.

[nekowinston]

So my understanding of this snippet (referenced from tree-sitter's nixpkgs shell completions) is that this is for pkgsCross cross compilation. First we need wasmtime completion to put the files under $out/share/{bash,fish,zsh} on our native architecture.
Then when building e.g. pkgsCross.armv7l-hf-multiplatform.wasmtime, buildPackages refers to the host architecture; the completions are copied from there to the cross-compilation target, since the build platform can't run wasmtime completion itself if it's targeting armv7.

I actually just tried this on my end with nix-build . -A pkgsCross.armv7l-hf-multiplatform.wasmtime and have noticed that our cargoShortTarget is wrong. I think it should be stdenv.hostPlatform instead of stdenv.targetPlatform, because the C API header cp fails.

[ereslibre]

Oh, I see, thank you. I didn't know this construct; out of interest I tried to use the second option and I run into infinite recursion, so I see now. The solution on this PR is working as expected:

❯ tree result
result
├── bin
│   └── wasmtime
└── share
    ├── bash-completion
    │   └── completions
    │       └── wasmtime.bash
    ├── fish
    │   └── vendor_completions.d
    │       └── wasmtime.fish
    └── zsh
        └── site-functions
            └── _wasmtime

[ereslibre]

Since we are optimizing, I'm wondering if it would make sense to add an option to skip wasmtime-cli, if a project only needs the C API.

@nekowinston oops, nvm, this is already possible by just building the dev output.

[nekowinston]

this is already possible by just building the dev output

Right now we're still always building both things, but most users will download just what they need from the binary cache.

[nekowinston]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 440501 --package pkgsCross.armv7l-hf-multiplatform.wasmtime.dev --package wasmtime --package wasmtime.dev --package pkgsCross.armv7l-hf-multiplatform.wasmtime
Commit: dfd0030eaba4c04c85e0ab298fd2cb9cba126b31

---

x86_64-linux

✅ 4 packages built:

• pkgsCross.armv7l-hf-multiplatform.wasmtime
• pkgsCross.armv7l-hf-multiplatform.wasmtime.dev (pkgsCross.armv7l-hf-multiplatform.wasmtime.dev.dev)
• wasmtime
• wasmtime.dev (wasmtime.dev.dev)

[ereslibre]

Thanks for the optimizations and fixing the cargoShortTarget issue!

[ereslibre]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 440501
Commit: dfd0030eaba4c04c85e0ab298fd2cb9cba126b31

---

x86_64-linux

✅ 2 packages built:

• wasmtime
• wasmtime.dev

[GaetanLepage]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 440501
Commit: dfd0030eaba4c04c85e0ab298fd2cb9cba126b31

---

x86_64-linux

✅ 2 packages built:

• wasmtime
• wasmtime.dev

---

aarch64-linux

✅ 2 packages built:

• wasmtime
• wasmtime.dev

---

x86_64-darwin

✅ 2 packages built:

• wasmtime
• wasmtime.dev

---

aarch64-darwin

✅ 2 packages built:

• wasmtime
• wasmtime.dev

[jcaesar]

Mmh, 69e1e80 broke building pkgsStatic.wasmtime (which is necessary if you have a nixos config like { boot.binfmt.preferStaticEmulators = true; boot.binfmt.emulatedSystems = ["wasm32-wasi"]; }.)

I'll see if I have time to figure out why and how to fix that… ([Edit:] It fails at rm $dev/lib/*.so{,.*}, which expands to rm. (nullglob?). Could be fixed by just doing rm -f … and thus ignoring the absence, but I'm entirely confused why this PR seems to expect it to build *.so files for static targets anyway…)
(Apologies, I had added that comment to the wrong pr once.)