Previous CMake issues/pull requests:
#1144
#5

#1573
#397
#255

The emscripten bits seem nice though :)

Note that i’ve been refactoring examples as part of the default branch, and will probably end up providing both premake and cmake files for the examples/ bits.

@franciscod, thanks for links. Now I have some ground to think about.
Looks like @tamaskenez make good work about this topic.
Another idea: publish default imgui_imp* code/libraries to simplify using of the ImGui.

Hi @ocornut, I implement idea to share ImGui_Impl* methods with users via CMake's package to easy create more examples or custom projects.
Please review examples/opengl2_example/CMakeLists.txt or examples/sdl_opengl2_example/CMakeLists.txt project files to see how users can use it.
Only one install ImGui package to your environment and use it anyware.
What your think about there idea?

@podgorskiy I understand why cmake is used. I personally think it's unnecessary for imgui as the point of the library is that you can register the .cpp file in your application and I encourage you to do so (you can add imgui cpp files from your main app cmake file).

Surely registering a few cpp files in your project shouldn't be harder than maintaining and registering a separate cmake file from your project?

Only one install ImGui package to your environment and use it anyware.

It is a little harmful as it prevents people from configuring ImGui for their application via imconfig.h. While people are free to repackage imgui if they like I think we shouldn't encourage it. ImGui is designed to be compiled in your engine/application and it is easy to compile (the absence of build files is an indicator that it doesn't need anything to be built).

That said, to provide the example applications I will maintain premake/cmake, but I won't tackle that until the examples are refactored in a later version. Your cmake references will be useful here. Thank you!

Also note that your PR also mix and matches multiple unrelated changes in a single commit so it's hard to review or pull.

FYI I made some comments but don't worry about reworking or splitting the PR. Since the examples are being refactored in the viewport branch, I won't be able take this PR soon. But I will pull the cmake/emscripten information from it so it is useful. Thanks again!

@podgorskiy I understand why cmake is used. I personally think it's unnecessary for imgui as the point of the library is that you can register the .cpp file in your application and I encourage you to do so (you can add imgui cpp files from your main app cmake file).

Surely registering a few cpp files in your project shouldn't be harder than maintaining and registering a separate cmake file from your project?

Just to play an advocate, I hate hate hate pulling in dependency code directly into my projects as it pollutes my repositories with code that is not mine to maintain.

As for ease of use, with cmake when I want to bring in a dependency then I'll add something like this in my CMake file (I'm using boost compiled libraries as an example as those are generally fairly painful otherwise, this shows the ease of use):

hunter_add_package(Boost COMPONENTS system filesystem)

At this point all the files needed for the system and filesystem parts of boost are downloaded and compiled at the default version in my linked repo (latest stable, others are available, and I can specify a version on the above line if you want a specific version that is older than the one in the dep lock file). I then use it like any other library:

find_package(Boost CONFIG REQUIRED system filesystem)
target_link_libraries(my_project Boost::system Boost::filesystem)

And that's it. To specify a lock file I just do:

HunterGate(
    URL "https://github.com/ruslo/hunter/archive/v0.16.15.tar.gz"
    SHA1 "6974c2150fc0d3b09de3ad1efcbf15d360647ffa"
)

And I can use multiple lock files if I so wish, which are combined in order as specified (so, just as an example, imgui could have it's own lock files of it's own versions if it didn't want to be listed in the main 'main' hunter dependency repository). If imgui could be built as a bog-standard cmake system then it could be added to such a repository system with trivial ease. There can be many versions of imgui there-of in the dependency system, for different branches, different actual versions, could be broken up into component parts or not, and the user doesn't have to worry about the API ever changing until they actually update HunterGate call's and/or change the version listed, it is very reproducible builds all while keeping third-party code out of your own code repository.

@ocornut, I review changes in vieport branch and can say - it's good :-)

It's okay that my changes can not be applied right now. We live in an era of change and this is normal. I am glad that there is a discussion on an interesting topic for me and that the results can be useful for everyone.
In my spare time I will track your changes and adopt my ideas.

I also think that I need to take into account the experience of @tamaskenez.

By the way, about the changes: what about moving the Demo functions in a separate header (for example, imgui_demo.h), because from the implementation is already separated.

Rebase on master and refactoring. Applied some experience from PR #1778.

Dear @ocornut, please review again and merge if possible.

Now possible install ImGui like:

cd examples
mkdir build && cd build
cmake ..
make install

Then copy example directory (for example example_glfw_opengl2) and use it as base for custom project.

Rebase on master. Add more bindings and examples.

Dear @ocornut, please review again and merge if possible.

Now implemented:

Export targets:

• ImGui::Library;
• ImGui::ImplFreeGLUT;
• ImGui::ImplSDL2;
• ImGui::ImplGlfw;
• ImGui::ImplOpenGL2;
• ImGui::ImplVulkan.

Import targets from:

• build directory;
• installed package.

Examples:

• example_null;
• example_freeglut_opengl2
• example_sdl_opengl2;
• example_sdl_vulkan;
• example_glfw_opengl2;
• example_glfw_vulkan.

Sorry I don't know when I can look at this in great details yet, but this looks solid. Thanks!
Some quick observations:

• Would it be possible to merge all the .cmake files into the same CMakeLists list so in examples/ it's all contained in less files? What's the reasoning for having CMakeList + ImGuiConfig.cmake + ImGuiModule.cmake + ImGuiTargets.cmake? How will the user interact with those files?

• Would it be possible to add a little more comments in the merged CMakeLists, with an emphasis at guiding people who are not expert of cmake who make want to look in there, maybe be able to make some changes if needed later, etc.

• Which are the .user file(s) added in the gitignore file?

• Do you think ImGui::Library would be more suitably renamed ImGui::Core ? Or is ::Library a common thing in cmake world?

Short ansver for .gitignore changes in #1919.

Ok. I will rename ImGui::Library to ImGui::Core (It's will be like Qt5::Core).

Technically I can implement everything in one file, but it will be difficult to understand.
I think several files are good, because every file does its job well.

Hi all! You are all right! It's hard for me to please everyone all at once. I am a supporter of incremental improvements. Let's say the Christmas miracle happens and basic CMake support is added, then the community can improve it. Let's... :-)

I don’t think those efforta are going to waste. The cmake pr and repos exist for this purpose. I am not against helping to make this more visible somehow.

Compiling/Linking with core Dear ImGui (without backends) is trivial. The problem is compiling/linking with dependencies required by backends. In principle if you have your own app running, you should ALREADY have a way to use those dependencies. It is tremendously difficult to provide a cmake that will nicely overlap with the myriad of ways those dependencies can be used and obtained. It is a problem for the Windows ecosystem mostly. If only Linux/osx existed providing those cmakefiles would likely be easier.

Third-party cmakefiles have the advantage that if they don’t work with your setup you are more likely to sidestep the problem.

I think most people complaining about the lack of an official cmakefile are misunderstanding this difficulty and the constraints they would add. @eliasdaler also wanted to make this happen at some point and ended up thinking it wasn’t easy to solve.

Yeah, I've tried here but eventually gave up.
I feel like CMake builds would be a bit more beneficial for backends if they lived in separate repos...

But for Dear ImGui itself - not really, it just has so many "manual" configuration tweaks that expressing it in CMake build script would be a huge burden to maintain. I had quite a lot of problems maintaining my own ImGui-SFML's CMake build... now imagine maintaining 5+ builds at once.

FYI in 1b27ac9 i have renamed imgui_impl_sdl.cpp to imgui_impl_sdl2.cpp as SDL3 is down the road (and we have a backend for SDL3 now). I wouldn't suggest bothering with the SDL3 part of building as the library is not going to be out for a while, but applying the renaming of the SDL2 backend will be needed.
(This change will unusually break lots of codebase but hopefully a trivial change).

Thanks for mentioning it here. I'll keep that in mind for the next update.

I have rebased this branch on latest:

• This include the imgui_impl_sdl -> imgui_impl_sdl2 renames.
• I didn't attempt to add SDL3 support (afaik there's no package for SDL3 yet)

I didn't push intermediary names e.g. cmake-v1.90, cmake-v1.91 etc as i don't have write access other than cmake. To recreate them, the easier is to checkout said version (e.g. check tag v1.90 on original) then cherry-pick 1 commit. There will be 1 conflict in glfw+vulkan example because I removed the ImTextureID define, just pick source from branch (the cmake projects afaik didn't add the ImTextureID define to build Vulkan/DX12 on 32-bit targets, but anyway it is not necessary anymore since 1.91.4).

Again, apologize for leaving that dangling. It's unlikely that I can devote full energy to this soon but one day I will. In the meanwhile it's nice having that cherry pickable commit for some people I suppose.

Rebased on latest release 1.91.7

I don't know why this PR can't be merged so long?

Rebased on latest release 1.91.7

The SDL3 support was added (+ SDLRenderer2/3 and examples)!

The Live Preview examples also updated (see links at start of page).

Rebased on latest release v1.91.8.

Rebased on latest release v1.91.9. Updated examples live preview.

Rebased on latest release v1.91.9b. Updated examples live preview.

Rebased on latest release v1.92.0. Bump minimum required CMake version to 3.5. Updated examples live preview.

If author won't accept this, we might able to release this in another unofficial repo which only have this changes?

I don't know what's best personally.
Using a separate repo would have one advantage that it becomes easy to add a CI task to automatically rebase on each commit?

External repo could fetch Dear ImGui code through ExternalProject (without build step) and implement build as necessary. No complicated rebases necessary.

Just to be clear:

If author won't accept this,

The problem on my end is that presently if I accepted this into master, it would mean people would increasingly rely on it, and support/maintenance of all building issues would fall on me. And my opinion this is opening a pandora box of problems. This has been corroborated by some discussions on X/BlueSky with other OSS maintainers suggesting that the experience of merging a CMakefile only increased the amount of building problems submitted by users.

That said I am obviously in favor of making things easier for users, and it is great that this exist. But I sincerely don't know what is the best way to move forward. If Konstantin wants to maintain an imgui_cmake repo that has those files + an imgui submodule, why not, this might be the better path? The irony is that IF it became popular, maintenance of build issues would increase and have to fall on someone. If Konstantin wants to take on that responsibility, I would do my best to promote it, we can even have it under https://github.com/dearimgui/ if they like. But IMHO the fact that this is presently a little bit off the main path and not officially supported is somehow a feature because it gate-keep the number of users and therefore of issues.

I don't know what cmake allows in term of package "fetching" but the core problem is that we want to make it flexible how/where people acquire their packages. Things are easy if you are e.g. 100% in vcpkg land. But some may want to use SDL3 binaries, some may want to fetch from git/web and build it from sources, some may want to vendor it and build it, some get it from brew, many scenarios are possible. If there was a clear path to allow user to permit any way of accessing a lib, a chunk of the problem would be simplified.

I am also generally not well equipped because I have little experience in CMake languages and idioms. I am not ruling out that I will eventually get on that board (especially if I try to spend more time in MacOS land).