vcpkg: 2025.02.14 -> 2025.04.09

[r-ryantm]

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/microsoft/vcpkg/releases.

meta.description for vcpkg is: C++ Library Manager for Windows, Linux, and macOS

meta.homepage for vcpkg is: https://vcpkg.io/

Updates performed

• Version update

To inspect upstream changes

Impact

Checks done

---

• built on NixOS
• The tests defined in passthru.tests, if any, passed
• found 2025.03.19 in filename of file in /nix/store/xdjp85hx5vkw1z1w2cg1xymzybvv0r4k-vcpkg-2025.03.19

---

Rebuild report (if merged into master) (click to expand)

8 total rebuild path(s)

8 package rebuild(s)

First fifty rebuilds by attrpath

_2ship2harkinian
cemu
imgui
imnodes
implot
sony-headphones-client
vcpkg

Instructions to test this update (click to expand)

---

Either download from the cache:

nix-store -r /nix/store/xdjp85hx5vkw1z1w2cg1xymzybvv0r4k-vcpkg-2025.03.19 \
  --option binary-caches 'https://cache.nixos.org/ https://nixpkgs-update-cache.nix-community.org/' \
  --option trusted-public-keys '
  nixpkgs-update-cache.nix-community.org-1:U8d6wiQecHUPJFSqHN9GSSmNkmdiFW7GW7WNAnHW0SM=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The nixpkgs-update cache is only trusted for this store-path realization.)
For the cached download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.

Or, build yourself:

nix-build -A vcpkg https://github.com/r-ryantm/nixpkgs/archive/e6018ddfc5ea391125f103652fba51b862ed304c.tar.gz

Or:

nix build github:r-ryantm/nixpkgs/e6018ddfc5ea391125f103652fba51b862ed304c#vcpkg

After you've downloaded or built it, look at the files and if there are any, run the binaries:

ls -la /nix/store/xdjp85hx5vkw1z1w2cg1xymzybvv0r4k-vcpkg-2025.03.19
ls -la /nix/store/xdjp85hx5vkw1z1w2cg1xymzybvv0r4k-vcpkg-2025.03.19/bin

---

Pre-merge build results

We have automatically built all packages that will get rebuilt due to
this change.

This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review

---

x86_64-linux

❌ 8 packages failed to build:

• _2ship2harkinian
• cemu
• imgui
• imgui.lib
• imnodes
• imnodes.dev
• implot
• sony-headphones-client

✅ 1 package built:

• vcpkg

---

Maintainer pings

cc @Guekka @gracicot @h7x4 for testing.

Tip

As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

---

Add a 👍 reaction to pull requests you find important.

[wegank]

cc @SomeoneSerge for the imgui regression

[r-ryantm]

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/microsoft/vcpkg/releases.

meta.description for vcpkg is: C++ Library Manager for Windows, Linux, and macOS

meta.homepage for vcpkg is: https://vcpkg.io/

Updates performed

• Version update

To inspect upstream changes

Impact

Checks done

---

• built on NixOS
• The tests defined in passthru.tests, if any, passed
• found 2025.04.09 in filename of file in /nix/store/1x4b0qr9svkl4i6p5gg3fav7ikd7hcij-vcpkg-2025.04.09

---

Rebuild report (if merged into master) (click to expand)

11 total rebuild path(s)

11 package rebuild(s)

First fifty rebuilds by attrpath

_2ship2harkinian
cemu
dartsim
imgui
imnodes
implot
python312Packages.dartsim
python313Packages.dartsim
sony-headphones-client
vcpkg

Instructions to test this update (click to expand)

---

Either download from the cache:

nix-store -r /nix/store/1x4b0qr9svkl4i6p5gg3fav7ikd7hcij-vcpkg-2025.04.09 \
  --option binary-caches 'https://cache.nixos.org/ https://nixpkgs-update-cache.nix-community.org/' \
  --option trusted-public-keys '
  nixpkgs-update-cache.nix-community.org-1:U8d6wiQecHUPJFSqHN9GSSmNkmdiFW7GW7WNAnHW0SM=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The nixpkgs-update cache is only trusted for this store-path realization.)
For the cached download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.

Or, build yourself:

nix-build -A vcpkg https://github.com/r-ryantm/nixpkgs/archive/43f81d48ee7de7811d8ba8f9f72eacded5531b0c.tar.gz

Or:

nix build github:r-ryantm/nixpkgs/43f81d48ee7de7811d8ba8f9f72eacded5531b0c#vcpkg

After you've downloaded or built it, look at the files and if there are any, run the binaries:

ls -la /nix/store/1x4b0qr9svkl4i6p5gg3fav7ikd7hcij-vcpkg-2025.04.09
ls -la /nix/store/1x4b0qr9svkl4i6p5gg3fav7ikd7hcij-vcpkg-2025.04.09/bin

---

Pre-merge build results

We have automatically built all packages that will get rebuilt due to
this change.

This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review

---

x86_64-linux

❌ 11 packages failed to build:

• _2ship2harkinian
• cemu
• dartsim
• imgui
• imgui.lib
• imnodes
• imnodes.dev
• implot
• python312Packages.dartsim
• python313Packages.dartsim
• sony-headphones-client

✅ 1 package built:

• vcpkg

---

Maintainer pings

cc @Guekka @gracicot @h7x4 for testing.

Tip

As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

---

Add a 👍 reaction to pull requests you find important.

[gracicot]

@Guekka @h7x4 Any idea why those 11 packages failed? If it's vcpkg that can't build a particular dependency I can take a look

[SomeoneSerge]

So far this isn't going too great, it's not good to block updates like this...

[gracicot]

I don't think applying patches to a vcpkg ports is a scalable solution to provide a CMake package for imgui. I looked more in depth and it seem we're borrowing vcpkg's CMake script to build imgui while upstream imgui does not offer a CMake package. Vcpkg cmake scripts are not meant to be used outside of vcpkg at all, and looking now upstream made the right choice to refuse the patch.

Honestly, I think we should not copy the vcpkg cmake script just to patch it, and instead we should provide our own CMake build script and update it as we need it. It would also remove an artificial dependency on the vcpkg package while keeping the feature you implemented. What do you think?

The following is probably a bit outside of the scope of this conversation, but I think the imgui nix package shouldn't try to expose a CMake package when imgui upstream does not support it and is not documented by upstream. If vcpkg's script makes it easier to use, then I would say the package wanting to use imgui with vcpkg's CMake script should use vcpkg as documented, then use the CMake package as documented.

On another note, the imgui community already wrote a single file CMake build script and they also have an active PR ocornut/imgui#3027 to add CMake right into imgui itself. Both solution don't need vcpkg and I think they are more suitable than the vcpkg specific build script.

[SomeoneSerge]

Now there's a get-merge-commit error, I'll rebase on master

[SomeoneSerge]

instead we should provide our own CMake build script and update it as

we need it Yes. One downside to this (the reason I went for introducing the explicit dependency) is this way we won't receive signal about our CMakeLists missing out on new features (like SDL3 in this case), instead we'll just silently build w/o those features.

looking now upstream made the right choice to refuse the patch

Yes, except for the part they kept their CMakeLists non-relocatable, which is a bit sus from CMake point of view AFAIK. They're in their right though

I think the imgui nix package shouldn't try to expose a CMake package

when imgui upstream does not support it In this case we might as well delete everything that depends on imgui. Upstream has had a semi-political stance about "imgui not requiring any build systems", which is just not how this works. The majority of the projects I came across, that consume imgui, consume it via Vcpkg's CMake interface, which I interpret as evidence that (1) a standardized interface is needed, (2) this interface is pretty much the only available.

an active PR ocornut/imgui#3027 to add CMake

I'm aware of the PR, so far it seemed more or less stalled, but if it ever comes through we'll obviously upgrade to it

[gracicot]

@SomeoneSerge

In this case we might as well delete everything that depends on imgui.
Upstream has had a semi-political stance about "imgui not requiring any
build systems", which is just not how this works. The majority of the
projects I came across, that consume imgui, consume it via Vcpkg's CMake
interface, which I interpret as evidence that (1) a standardized
interface is needed, (2) this interface is pretty much the only available.

I haven't notice imgui had no proper build system, so accounting for this I think the approach of providing our own script makes the most sense. Thanks for pointing this out.

Yes. One downside to this (the reason I went for introducing the
explicit dependency) is this way we won't receive signal about our
CMakeLists missing out on new features (like SDL3 in this case), instead
we'll just silently build w/o those features.

Right now our users are missing both on vcpkg and imgui features.

I think a good solution would be to still use vcpkg source in imgui, but not use the vcpkg package from nix to get them. This would mean a de coupling between vcpkg and imgui which would completely prevent situation like today, and still provide the feature imgui users depends on. One would need to update imgui in a PR to provide new feature, but IMO that would be better for users in general.

I can open a PR to discuss this.

I'm aware of the PR, so far it seemed more or less stalled, but if it
ever comes through we'll obviously upgrade to it

Sounds good.

[SomeoneSerge]

Had to force-push again because of the formatting check.

I think a good solution would be to still use vcpkg source in imgui, but not use the vcpkg package from nix to get them. This would mean a de coupling between vcpkg and imgui

In this case I'd introduce an extra fixpoint at the top-level, something like vcpkgForCmakeLists, so that (1) it's automatically updated by r-ryantm, (2) that we ensure overrides are still easy, and (3) we're not tempted to pin a hundred different revisions of vcpkg. We could also move all (package-specific) ports patches in a centralized way, instead of calling vcpkg.overrideAttrs in implot, imgui, and potentially others.

I can open a PR to discuss this.

I'd be very grateful! It's obviously my responsibility for introducing the dependency in the first place, but I'm afraid I'm kind of slow...