imgui: ship vcpkg' (cmake) distribution info #303682
Conversation
SomeoneSerge
force-pushed
the
feat/imgui-cmake
branch
from
670d3fe
to
5021572
Compare
SomeoneSerge
force-pushed
the
feat/imgui-cmake
branch
4 times, most recently
from
4ac25c6
to
0cbacb0
Compare
SomeoneSerge
changed the title
|
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 |
| cmakeRules = "${vcpkg.src}/ports/implot"; | ||
| postPatch = '' | ||
| cp "$cmakeRules"/CMakeLists.txt ./ |
There was a problem hiding this comment.
| 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?
There was a problem hiding this comment.
This is so as to keep phases agnostic of the hashes. I see no good reason to render the hashes into the scripts
There was a problem hiding this comment.
I can't follow you.
Usually turning nix variables into bash variables is an anti pattern we try to avoid.
There was a problem hiding this comment.
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 😆
There was a problem hiding this comment.
You should be able to use finalAttrs to allow overrides like that, too.
There was a problem hiding this comment.
That's an option, but it's not really any better than eliminating the template rendering and treating postPatch as a normal setup hook
SomeoneSerge
force-pushed
the
feat/imgui-cmake
branch
from
0cbacb0
to
ea9d642
Compare
SomeoneSerge
force-pushed
the
feat/imgui-cmake
branch
from
b52a5fa
to
aa8d8cb
Compare
SomeoneSerge
changed the title
| # [^1]: https://github.com/microsoft/vcpkg/blob/095ee06e7f60dceef7d713e3f8b1c2eb10d650d7/ports/imgui/CMakeLists.txt#L33-L108 | ||
| IMGUI_BUILD_ALLEGRO5_BINDING ? false, | ||
| IMGUI_BUILD_ANDROID_BINDING ? stdenv.hostPlatform.isAndroid, | ||
| IMGUI_BUILD_DX9_BINDING ? false, | ||
| IMGUI_BUILD_DX10_BINDING ? false, | ||
| IMGUI_BUILD_DX11_BINDING ? false, | ||
| IMGUI_BUILD_DX12_BINDING ? false, | ||
| IMGUI_BUILD_GLFW_BINDING ? !glfw.meta.unsupported && !libGL.meta.unsupported, | ||
| IMGUI_BUILD_GLUT_BINDING ? false, | ||
| IMGUI_BUILD_METAL_BINDING ? stdenv.isDarwin, | ||
| IMGUI_BUILD_OPENGL2_BINDING ? false, | ||
| IMGUI_BUILD_OPENGL3_BINDING ? | ||
| IMGUI_BUILD_SDL2_BINDING || IMGUI_BUILD_GLFW_BINDING || IMGUI_BUILD_GLUT_BINDING, | ||
| IMGUI_BUILD_OSX_BINDING ? false, | ||
| IMGUI_BUILD_SDL2_BINDING ? | ||
| !IMGUI_BUILD_GLFW_BINDING && !SDL2.meta.unsupported && !libGL.meta.unsupported, |
There was a problem hiding this comment.
I decided to replace lists and maps with the boilerplate. It's stupid and easy to get lost in when editing, but it makes more sense as an interface and mimics vcpkg options exactly. Most of these options currently set broken = true, but the default instantiations like SDL/glfw3 on linux work as expected
| # CMake: link libGL from the "app" target | ||
| (fetchpatch { | ||
| url = "https://github.com/epezent/implot_demos/commit/6742e4202858eb85bd0d67ca5fa15a7a07e6b618.patch"; | ||
| hash = "sha256-h4EJ9u1iHLYkGHgxSynskkuCGmY6mmvKdZSRwHJKerY="; | ||
| }) |
There was a problem hiding this comment.
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
ofborg
bot
added
10.rebuild-darwin: 11-100
10.rebuild-linux: 101-500
and removed
10.rebuild-darwin: 1-10
10.rebuild-linux: 1-10
labels
There was a problem hiding this comment.
@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?
There was a problem hiding this comment.
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
Glfw may dlopen libwayland-client.so. This was observed when testing .#imgui.tests.demo
SomeoneSerge
force-pushed
the
feat/imgui-cmake
branch
from
48d0e4c
to
38a479a
Compare
SomeoneSerge
changed the title
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
imguiand related packages to reusevcpkg'CMakeLists.txtinstead of custom phases.Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.