ImGui Integration with vcpkg

[mosra]

ImGui Integration with vcpkg

[fauder]

Gotcha. Thanks for the help and also for creating Magnum!

[devpikachu]

As of now, the solution I've found works best is still explained here: mosra/magnum-examples#97 (comment)

TL;DR: Clone imgui and magnum-integration locally and build with bundled ImGui.

CMake:

set(IMGUI_DIR ${CMAKE_CURRENT_SOURCE_DIR}/lib/imgui)
set(WITH_IMGUI ON CACHE BOOL "" FORCE)
add_subdirectory(lib/magnum-integration EXCLUDE_FROM_ALL)

Note that I have mine under ./lib/ - adapt to your own use-case.

[mosra]

Hi!

I'm not a "Windows native" user so I don't know how exactly the package works -- however, if I remember correctly, ImGui had various issues when built dynamically. Can you try using the static build instead (it's the x64-windows-static triplet if I remember correctly)? That one should work.

Also, do you remember what were the errors with SDL? There's a chance I already saw those and could point you in the right direction. Other than that the GLFW and SDL app implementation should have mostly a feature parity, so you're not missing out on anything (the only reason why SDL is default is that it works on phones and the web also, which GLFW doesn't).

You can use Magnum without CMake, yes (and as long as you are directly in the VS IDE, vcpkg should "magically work" for everything, no need to supply link libraries or include directories ... or that was its main selling point, at least). Some things however (such as compiling resources) might be harder than when using Magnum's CMake support tho. Some docs that might be useful.

[mosra]

I dug into the vcpkg package history and it seems that dynamic builds might have worked in the past, but they certainly don't anymore (unless imgui itself is doing something for that, which I doubt): microsoft/vcpkg@050e71d#diff-99430a8c55cefb8a2e543d865102898d

A random idea: could you try putting the set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON) line back into your copy of ports/imgui/CMakeLists.txt and installing the package again? I think that could fix it.

Looking at microsoft/vcpkg#5937, from which the above originates, it seems that certain ports reverted this change and I think imgui could do the same ... or some cleaner variant of it. (@Squareys do you think you could have time to do this?)

[fauder]

It already says

Note: imgui only supports static library linkage. Building static library.

when installing imgui through vcpkg. Although I tried it anyways and nothing changed.

Going to try modifying CMakeLists.txt in ports/.

[fauder]

A random idea: could you try putting the set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON) line back into your copy of ports/imgui/CMakeLists.txt and installing the package again? I think that could fix it.

This also did not work, same linker errors.

[fauder]

I noticed I have both imgui:x64-windows and imgui:x64-windows-static

So I removed all x64-windows packages and installed all of them with x64-windows-static ones. Now I can build and run the imgui example!

You might want to update magnum-integration build docs, mention this imgui-static issue.

Also, do you remember what were the errors with SDL?

cannot open source file "SDL_keycode.h
cannot open source file "SDL_mouse.h
cannot open source file "SDL_version.h
cannot open source file "SDL_video.h
cannot open source file "SDL_scancode.h

Even though I have sdl2:x64-windows-static installed.

You can use Magnum without CMake, yes (and as long as you are directly in the VS IDE, vcpkg should "magically work" for everything, no need to supply link libraries or include directories ... or that was its main selling point, at least). Some things however (such as compiling resources) might be harder than when using Magnum's CMake support tho. Some docs that might be useful.

The link you attached seems a little overwhelming. I hope I can manage.

Thanks for the tip and of course for Magnum!

[mosra]

Regarding the SDL includes -- vcpkg has a patch to fix those (https://github.com/microsoft/vcpkg/blob/master/ports/magnum/001-sdl-includes.patch) but looks like it doesn't apply on current master anymore, which is why you get the errors. That needs to get fixed, a temporary workaround is to add the path to the SDL2/ subdirectory of SDL includes to your Visual Studio project. But GLFW is working just fine and is free of issues like #57, so no need to switch back :)

Note: imgui only supports static library linkage. Building static library.

Good to know -- then Magnum may need an adjustment to work correctly as a dynamic library linked against a static lib. If you can keep using the static build until then, great.

overwhelming

The most scary parts are the library dependency graphs. That dependency ordering is already handled for you by vcpkg, so not really needed :)

[fauder]

I'm happy with GLFW :) I also don't (currently) have a problem with static build. Is there a disadvantage to linking against Magnum statically ?

The most scary parts are the library dependency graphs. That dependency ordering is already handled for you by vcpkg, so not really needed :)

Hmm, what about this then:

Some things however (such as compiling resources) might be harder than when using Magnum's CMake support tho.

Does this mean I may run into problems when compiling shaders into resources ? I apologize if I am not making sense, I'm still trying to learn how Magnum handles anything (including shaders).

More general question: I plan on migrating a codebase of not-insignificant size built upon MFC to Magnum (and ImGui for GUI). Can I get by with vcpkg approach ? For example; I plan on using geometry shaders. Would compiling shaders be a problem with the vcpkg approach (since you mentioned compiling resources) ?

My main issue (compiling ImGui example) is solved by the way, thanks!

[mosra]

There's no disadvantage to linking statically (apart from the usual tradeoffs with static/dynamic builds) :)

You're not forced to use Utility::Resource for anything, but if you would want to use it to embed data in your executable (instead of having external files), you need to manually invoke corrade-rc as part of your build and then add the generated cpp file to your project sources. You are also free to use any other method that suits your workflow (such as Windows *.rc files, if you only need to care about Windows). Go through the Textured Triangle example to get an idea what issues you might run into -- again, the example will work just fine with shader sources loaded directly from files.

I'm keeping this issue open as a reminder to fix the two vcpkg-related issues (otherwise there's high chance those would get forgotten).

[mosra]

The SDL-related issue should be fixed once microsoft/vcpkg#10158 gets merged. ImGui will likely need more work, that's not done yet.

[pezcode]

Just ran into this issue trying to compile magnum-integration from source while linking to libraries from vcpkg with a x64-windows-static triplet. When MAGNUM_IMGUIINTEGRATION_BUILD_STATIC is not defined, it defines IMGUI_API to __declspec(dllimport) which results in linker errors because the vcpkg imgui.lib is a static library.

One solution I could think of would be:

• don't define IMGUI_API in visibility.h
• find out the linked imgui library type (e.g. through the TYPE target property)
• propagate that information to imgui and anyone using the headers, probably with target_compile_definitions on ImGui::ImGui

[mosra]

Yep, TYPE target property is a good idea -- does the ImGui CMake config coming from Vcpkg expose this information? For all I know, imported targets usually lack info whether a library is static or dynamic and so I had to always revert to guessing from library filename (which isn't really possible on Windows).

Another alternative, as mentioned in one of the comments above I think, would be always compiling ImGuiIntegration as static, which could prevent issues with global symbols duplicated across DLLs (unless the end-user links the static lib into two DLLs again).

[pezcode]

does the ImGui CMake config coming from Vcpkg expose this information? For all I know, imported targets usually lack info whether a library is static or dynamic and so I had to always revert to guessing from library filename (which isn't really possible on Windows).

The CMake config file installed by vcpkg does this:

# Create imported target imgui::imgui
add_library(imgui::imgui STATIC IMPORTED)

Mildly relevant quote from the CMake docs:

An UNKNOWN library type is typically only used in the implementation of Find Modules. It allows the path to an imported library (often found using the find_library() command) to be used without having to know what type of library it is. This is especially useful on Windows where a static library and a DLL’s import library both have the same file extension.

[bigdimboom]

Is there a definitive solution for issue yet? I have the issue on windows vs 2019.