imgui: ship vcpkg' (cmake) distribution info

[SomeoneSerge]

Description of changes

"Dear ImGui" is one instance of a project where upstream chooses to only distribute sources and headers without any metadata related to building or packaging (cmake "modules", pkg-config, ...). In practice, building and managing the dependencies of imgui, or including imgui in projects built by common build tools (cmake, meson, ...) are not trivial. One way to consume it, besides vendoring, is via the cmake rules maintained in a centralized repository like vcpkg (conan, ...). Presumably, it's even a quite common method.

A wider adoption of the vcpkg-like approach by upstream projects would be ideal for Nixpkgs purposes: it establishes a common interface and a dependency injection mechanism that help creating consistent package sets, fix points, modeling dependencies as independent derivations, etc. This common interface is in fact pure cmake and vcpkg-agnostic. Possibly worth a mention that vcpkg is licensed under MIT.

I suggest we try out the practice of distributing vcpkg' packaging info in situations where upstream doesn't provide any.

In this PR I adapt imgui and related packages to reuse vcpkg' CMakeLists.txt instead of custom phases.

Affected packages:

• glfw3
• imgui
  • implot
  • imnodes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/3795

[SuperSandro2000]

Suggested change

	cmakeRules = "${vcpkg.src}/ports/implot";
	postPatch = ''
	cp "$cmakeRules"/CMakeLists.txt ./
	postPatch = ''
	cp "${vcpkg.src}/ports/implot"/CMakeLists.txt ./

or is this used as an env?

[SomeoneSerge]

This is so as to keep phases agnostic of the hashes. I see no good reason to render the hashes into the scripts

[SuperSandro2000]

I can't follow you.

Usually turning nix variables into bash variables is an anti pattern we try to avoid.

[SomeoneSerge]

Introducing the auxiliary variable like this gives the opportunity to implot.overrideAttrs (_: { cmakeRules = ./my-custom-cmake; }) which otherwise would require a careful surgery on the postPatch. I've been following a similar pattern outside the tree and thought it wouldn't do harm to do the same here.

an anti pattern we try to avoid.

Yesssss setup-hooks are an anti-pattern, let's make nix evaluation faster and abolish setup hooks 😆

[SuperSandro2000]

You should be able to use finalAttrs to allow overrides like that, too.

[SomeoneSerge]

That's an option, but it's not really any better than eliminating the template rendering and treating postPatch as a normal setup hook

EDIT: Note also, this would still require the auxiliary variable

[SomeoneSerge]

vcpkg' CMakeLists.txt for imgui doesn't target_link_libraries(... OpenGL::GL). I wasn't sure if it should, so for now I made the demo link libGL explicitly

[SomeoneSerge]

@SuperSandro2000 any concerns other than hooks-vs-finalAttrs? More generally, do you have any opinion on the decision to adopt 3rd party (vcpkg) distribution information?

[SomeoneSerge]

I'd like to merge tomorrow unless there are objections.

@SuperSandro2000 we haven't reached the agreement on the finalAttrs matter but we can keep the question open and if we end up choosing against bash variables I'll just open a follow-up PR

[SomeoneSerge]

Well if there should be any objections they can be resolved in future PRs.

RE: Ofborg

• Aarch64-linux builds fine locally (can't post a nixpkgs-review because my aarch64 builder doesn't have enough storage for the whole thing 🙈)
• I can't test Darwin, it's something to follow up on

[wegank]

I can't test Darwin, it's something to follow up on

And I guess this PR does break imgui on darwin....

[SomeoneSerge]

And I guess this PR does break imgui on darwin....

Well, "breaks" is maybe an overly strong way to put it, given that previously this derivation didn't actually "build" imgui. As I mentioned in the update, clients that prefer the "add_subdirectory" approach can still use imgui.src.

I'll try to clean this up rn

[wegank]

Opened #315917, it's just missing some frameworks.