Add simple CMake support for imgui

[jiapei100]

1. Add simple CMakeLists.txt to build imgui into a shared library, and add the options to build a couple of more backend modules, as well as examples.
2. SDL is now supporting version 2, namely: SDL2.

[rokups]

Cool that you chose to implement build in a single file, not littering entire project with CMake-isms! There already were other attempts, adding them for reference: #4614, #3027, #2820, #2033, #1778, #1713, #1573, #255, CMakeLists.txt. Wow, this was a lot. Seems like there is a persistent demand, even though building Dear ImGui does not require any special build steps and is easy to include as part of your project, whatever build system is used.

This PR is by no means complete though. I love simplicity of this build script, but unfortunately it will not be enough to build all examples on most supported operating systems. If you look at my linked CMakeLists.txt you would find that (unfortunately) there are too many ways to find dependencies. All these ways are unfortunately necessary to take into account, because a combination of each supported OS + CMake version has or does not have certain bits. For example, you use PkgConfig cmake package. This will not work on windows when targeting MSVC. Certain dependencies on certain OS can be found via pkg-config, other dependencies wont have .pc script, but can be found through CMake's find_package(). Sometimes it is useful to be able to build these dependencies from source. Also one must consider that users would use this build script in their projects, therefore we must support usecase through add_subdirectory(). In such cases users may want to use dependencies that already exist in their project (for example SDL/GLFW), but library targets may have different names. Apple's examples deserve a special pot in hell, i have not been able to fully sort out fully building anything beyond example_apple_opengl2. And so list goes on... This sounds like a simple problem, but when you start to consider all edgecases it spirals out of control 😞

SDL is now supporting version 2, namely: SDL2.

This is incorrect use of SDL. By convention users must import SDL with it's special include paths:

~ % pkg-config --cflags sdl2   
-I/usr/include/SDL2 -D_REENTRANT

You on the other hand changed includes in a way that depends on /usr/include being available in include path, disregarding windows.

set(CMAKE_CXX_STANDARD 14) # Enable c++14 standard

Dear ImGui requires C++11, there is no point to force a higher standard version. Also care must be taken to allow users to set higher version should they desire. This would be best done through target_compile_features().

include_directories(./)

This is a big no-no. With modern CMake we use target-based approach, assigning include paths to targets. You should use target_include_directories() and other calls starting with target_ so we would not have to rewrite build script later.

All in all this build script only covers a tiny fraction of usecases - building of examples for demonstration purposes on Linux. A lot more work is still required. But maybe its a good start! 👍

[Hish15]

This has nothing to do with this repo. It is recommended to put this on a toolchain file, the user can do this on it's side

[Hish15]

Two things with this

• This is expected to be 11
• This must be set at the target level. You are polluting the global scope!

[Hish15]

List the sources directly here

[Hish15]

Suggested change

set(SOURCE_FILES imgui.cpp imgui_draw.cpp imgui_demo.cpp imgui_tables.cpp imgui_widgets.cpp) # Add all .cpp files of project root directory as source files

[Hish15]

Put all options together and as high as possible on the file

[Hish15]

Suggested change

	set(BACKEND_FILE ./backends/imgui_impl_allegro5.cpp)
	add_library(imgui_backend_allegro5 ${BACKEND_FILE})
	add_library(imgui_backend_allegro5 backends/imgui_impl_allegro5.cpp)

[Hish15]

Use target version

[Hish15]

Suggested change

	set(EXAMPLE_MAIN_FILE ./examples/example_apple_opengl2/main.mm)
	add_executable(example_apple_opengl2 ${EXAMPLE_MAIN_FILE})
	add_executable(example_apple_opengl2 examples/example_apple_opengl2/main.mm)

[Hish15]

Suggested change

	if(${BUILD_EXAMPLE_ALLEGRO5})
	if(BUILD_EXAMPLE_ALLEGRO5)

[Hish15]

This is not needed with properly set targets

[Endilll]

@rokups are there other reasons besides building examples on Apple why you haven't already created a PR out of your CMakeLists? It looks quite comprehensive and addresses at least some of the points you mentioned.

[rokups]

Build systems are a complicated can of worms. Adopting a build script implies maintenance. Current build infrastructure (vcxproj + Makefile) are not used by people so they only need to be maintained as much as we need to use them for testing or on CI. A comprehensive CMakeLists will be used by people so it will definitely be more work maintaining that as well. In the end it is pretty trivial for everyone to come up with a minimal CMakeLists for imgui, that fits their project needs. Even in my own sideprojects i just throw couple lines simple CMakeLists and use that instead of using my script as it is just simpler.

tl;dr; there is no real hard need for that so its on hold. maybe one day, maybe not, who knows \o/

[SomeoneSerge]

even though building Dear ImGui does not require any special build steps and is easy to include as part of your project, whatever build system is used

Offtopic but this very much sounds like https://youtu.be/sBP17HQAQjk?t=318 🤣

I'm wondering if maybe at this point it's more sensible to just advertise vcpkg's (or equivalent) cmake rules for imgui. From bootstrapping and/or distributions' points of view, people vendoring imgui is an issue, because that is usually done in a way that prevents substitution/dependency injection. Just having standardized pkg-config/cmake target names (e.g. ones declared by vcpkg) that people could test for before falling back to their vendored stuff would already be quite helpful