ocornut
Add CMakeLists.txt for project
The current build system relies on Visual Studio 2019, which is outdated and somewhat difficult to work with.
After some analysis, I believe the project can be built more cleanly with a simple CMakeLists.txt. I tested this approach in my local fork and it works well. You can check the commit here:
https://github.com/ocornut/imgui_test_engine/commit/ca6e84977b2abaf1c9de92557e6c081814cd8486
I forgot to mention: CMake assumes that the ImGui sources are located in the imgui/ directory.
I don’t understand the remark about being “outdated”. Any news version of Visual Studio can should be able to load and update the project. It is intentionally kept at an older version to support as many as possible.
Can you clarify “difficult to work with” ?
If VS2022 is used to open and upgrade the solution, many files get updated in Microsoft’s private formats. Even small actions in the IDE can cause XML changes, which makes it difficult to review and track in git. Cleaning the private files will be extra work when making PR.
Below is just a personal opinion:
I switched from Visual Studio to VS Code a long time ago because I needed a consistent working environment across Windows and Linux, as well as support for multiple programming languages. VS Code allows me to update extensions from the community and even generate(by AI) my own when the IDE doesn’t meet my needs — for example, vscode-background-tint.
VS Code gives that flexibility, whereas Visual Studio does not. It’s the same reason I moved from wxWidgets to imgui. (wxWidgets is a very good project, and I used it for a long time.)
If VS2022 is used to open and upgrade the solution, many files get updated in Microsoft’s private formats. Even small actions in the IDE can cause XML changes, which makes it difficult to review and track in git. Cleaning the private files will be extra work when making PR.
I don't agree with those statements. Small actions in IDE don't cause XML changes. You must be adding wrong type files (such as .user files) to your solution.
I however agree that a CMakeLists would be preferable to facilitate use in VS Code. However most people vastly underestimate and misunderstand the complexity of providing a CMake setup for APPLICATIONS, that works everywhere and doesn't put constraints on where the libraries are pulled from. I polled many library authors in the C++ ecosystems and most stated that they regretted adding Cmakelist because it opened a wider number of problems. I would rather have no CMakelist than one that adds extra constraints to how dear imgui is used.
Practically 95%+ of the cmake submission in imgui repo are incomplete or wrong or caused problems when I tried them. Most people submitting them don't test their stuff with a wide enough range of setups. https://github.com/ocornut/imgui/pulls?q=is%3Aopen+is%3Apr+label%3Abuilding 8896 and 1713 appears to be the better one (but I'm not sure and must have missed some) and for neither I had the time/energy to take them to the quality I would want. But I will, eventually.
Note that providing one for the imgui_test_engine LIBRARY which doesn't have non-standard dependencies is easy and could be considered. But one for imgui_test_suite is more difficult.
You're right — CMake is powerful but its syntax can be awkward and non‑intuitive. I’ve submitted a few CMake-related PRs to other projects when the issue was obvious.
For the test engine I agree that providing it as a library is a better approach. Alternatively, users can add a dedicated CMakeLists.txt for their environment — that’s what I do locally and it’s straightforward.
Btw, I just realized I haven't check any CMake related issues in ImGui repo, because I usually start from the hello_imgui boilerplate; I did send a PR to hello_imgui recently.
This ticket is just a discussion:), we could close this issue if we are not changing cmake recently.