Any guidance on how to test Marmalade apps would be appreciated. I'd be happy to add the configuration for them.

Hey i like clarity of CMake code in this PR. Great job 👍

I have a few commends:

imgui-sdl vs imgui_example_sdl_opengl3 naming style. Any particular reason you mix - with _?

I think it would be very convenient if we could have all of cmake scripts in one file. I know this is not exactly conventional in CMake projects. Reason i am suggesting it is because Dear ImGui is a multi-buildsystem project and CMake support would be an addon instead of a main build system. Example targets could be created by one-liner if we made a macro for it. Defining most examples is almost same.

Third party dependencies could use some touching up. For example if imgui-sdl was INTERFACE library we could essentially omit it from visible targets and avoid polluting user's targets list. Libraries, includes and even source files can be added to a target using INTERFACE visibility to achieve exact same result. Note that it is important to allow users to link their own SDL/GLFW/etc in-tree dependencies.

imgui-sdl should use pkg-config on MacOS. Also newer CMake creates SDL2::SDL2 imported target which users are supposed to link. Here is example of how i handle it:

if (NOT DEFINED IMGUI_SDL_TARGET)
    find_package(SDL2 QUIET)
    if (TARGET SDL2::SDL2)
        # Some platforms (Linux) have SDL target properly exported as CMake target.
        set (IMGUI_SDL_TARGET SDL2::SDL2)
    elseif (SDL2_FOUND)
        # Platforms that do not export target but use old CMake conventions can be handled this way.
        add_library(SDL2::SDL2 INTERFACE IMPORTED)
        target_link_libraries(SDL2::SDL2 INTERFACE ${SDL2_LIBRARIES})
        target_include_directories(SDL2::SDL2 INTERFACE ${SDL2_INCLUDE_DIRS})
        set (IMGUI_SDL_TARGET SDL2::SDL2)
    elseif (NOT "$ENV{SDL2_DIR}" STREQUAL "")
        # On windows we may set SDL2_DIR environment variable and link to binary SDL distribution.
        add_library(SDL2::SDL2 INTERFACE IMPORTED)
        set_target_properties(SDL2::SDL2 PROPERTIES
            INTERFACE_INCLUDE_DIRECTORIES $ENV{SDL2_DIR}/include
            INTERFACE_LINK_LIBRARIES "$ENV{SDL2_DIR}/lib/${IMGUI_PLATFORM_ARCH}/SDL2.lib;$ENV{SDL2_DIR}/lib/${IMGUI_PLATFORM_ARCH}/SDL2main.lib"
        )
        set (IMGUI_SDL_TARGET SDL2::SDL2)
        add_custom_target(CopySDL ALL COMMAND ${CMAKE_COMMAND} -E copy
            "$ENV{SDL2_DIR}/lib/${IMGUI_PLATFORM_ARCH}/SDL2.dll" "${IMGUI_OUTPUT_DIR}/$<CONFIG>/SDL2.dll")
        add_dependencies(${IMGUI_SDL_TARGET} CopySDL)
    elseif (PkgConfig_FOUND)
        # Rest of the platforms (like MacOS) can consume SDL via pkg-config.
        pkg_check_modules(SDL2 QUIET IMPORTED_TARGET sdl2)
        if (SDL2_FOUND)
            set (IMGUI_SDL_TARGET PkgConfig::sdl2)
        endif ()
    endif ()
endif ()

This is not perfect, but could serve as a starting point. CopySDL is especially bad, but i failed to get CMake copy a DLL even though it is supposed to be able to.

My GLFW bit:

    if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/../glfw/CMakeLists.txt)
        # When parent directory contains GLFW source code - we can build it directly.
        set (GLFW_STANDALONE OFF)
        set (GLFW_INSTALL OFF)
        set (GLFW_BUILD_DOCS OFF)
        add_subdirectory (${CMAKE_CURRENT_SOURCE_DIR}/../glfw ${CMAKE_CURRENT_BINARY_DIR}/glfw)
        set (IMGUI_GLFW_TARGET glfw)
    elseif (MSVC)
        # We ship compiled libraries in our repository for Visual Studio.
        add_library(glfw INTERFACE IMPORTED)
        target_link_libraries(glfw INTERFACE libs/glfw/lib-vc2010-${IMGUI_PLATFORM_BITS}/glfw3.lib)
        target_include_directories(glfw INTERFACE libs/glfw/include)
        set (IMGUI_GLFW_TARGET glfw)
    elseif (PkgConfig_FOUND)
        pkg_check_modules(GLFW QUIET IMPORTED_TARGET glfw3)
        if (GLFW_FOUND)
            set (IMGUI_GLFW_TARGET PkgConfig::glfw)
        endif ()
    endif ()

Any guidance on how to test Marmalade apps would be appreciated. I'd be happy to add the configuration for them.

You can ignore this, I am going to scrap that backend and move it elsewhere eventually.

Hey @rokups, thanks for the feedback!

Any particular reason you mix - with _?

Yes - using the - in library names is typical of target names in CMake, namely libraries (sometimes you get weird variances, e.g. I've seen static library targets denoted with a _a, as is the case with libuv). I use _ in the executable names because that doubles as the output executable's name (e.g. imgui_example_sdl_opengl3.exe) and they won't be used by any consuming application.

I think it would be very convenient if we could have all of cmake scripts in one file.

I'll defer to @ocornut here, but I will say this: it is indeed very unconventional, and it's going to hurt maintainability in the long-term. I highly recommend against it.

we could essentially omit it from visible targets

I didn't know INTERFACE libraries did this - how are they supposed to be consumed, then? Can you find a link that talks about INTERFACE libraries not being visible? As-is, they are object libraries, meaning we can control the build flags that go into the implementations but they are not linked together or archived into a library file (and are thus just included as object files in the consuming application).

Note that it is important to allow users to link their own SDL/GLFW/etc in-tree dependencies.

Definitely; this is how I intend to use ImGui in my projects as well. I still need to test, but I've written the configuration with this in mind, and I believe the current configuration allows for this. If not, NOT TARGET clauses can be trivially added, or even option()s (which is pretty typical - you see it a lot with SSL-enabled libraries, for example).

imgui-sdl should use pkg-config on MacOS. Also newer CMake creates SDL2::SDL2 imported target which users are supposed to link. Here is example of how i handle it:

I'll give it a shot, thanks :)

You can ignore this

Sounds good; what about allegro? I'm not familiar with that either.

@rokups your glfw pkgconfig code seems to fail for me:

CMake Error at examples/example_glfw_opengl3/CMakeLists.txt:2 (add_executable):
  Target "imgui_example_glfw_opengl3" links to target "PkgConfig::glfw3" but
  the target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?

Can you find a link that talks INTERFACE libraries not being visible?

Imported library description does not mention this property. I guess invisibility is a byproduct of library not producing any output. And they arent object libraries as object libraries are ones that compile source files but do not link them into libraries/exes. They just inject extra includes/libs/flags to linking target. But we can exploit them to also inject source files to linking targets by using target_sources().

@rokups your glfw pkgconfig code seems to fail for me

Could maybe CMake version being rather old? See https://cmake.org/cmake/help/v3.17/module/FindPkgConfig.html?highlight=pkg%20config#module:FindPkgConfig for your version of CMake. PkgConfig:: prefix is not something that existed from 3.1.

I guess invisibility is a byproduct of library not producing any output

This seems strange. Targets shouldn't be able to conflict - CMake wouldn't know what to do. I think there's a missing piece of information somewhere here 😅

In your opinion, what are the pros/cons of using import libraries vs. object libraries?

Could maybe CMake version being rather old?

$ cmake --version
cmake version 3.16.2

Hello @Qix-, add Emscripten to platforms (example_emscripten). More there,

@podsvirov I didn't add it since it's not an impl. It uses SDL and opengl3 under the hood - it's just a compiler change.

EDIT: nevermind, I see what you mean. Added :)

@Qix-, any efforts to export your configuration for others and install examples?

PS: my acount is @podsvirov :-). Dear @podgorskiy, sorry for noise.

Whoops, sorry about that. Don't know why github did that. 😅 (EDIT: Oh I see he's also active around here; yes, sorry for the noise indeed!)

What do you mean by exporting configuration? As far as installation, I don't know that examples really need to have install targets.

Yes, we can simply built examples, but then we simply build only examples...
Have you experience to build and export CMake package for others?

I don't understand what you mean by "package". Packaging what, and for whom? ImGui examples aren't going to be used by anyone outside the project, so there's no point in having an install target for them. What's the use-case? I'm pretty reluctant on adding anything that doesn't need to be added.

What is holding back the vulkan stuff? I see the cmake files in the commit.

@Cazadorro I only have a mac machine and (correct me if I'm wrong) ImGui doesn't have a MoltenVK sample (I've never worked with moltenvk personally).

Further, you can't test Vulkan in virtual machines yet (at least, VMWare doesn't support it). Just compilation, but that doesn't tell me if it actually runs or not.

I haven't used moltenvk, but theoretically it should be exposed the same way as vulkan, so I don't think it would require a code change to support. Do you need people to run things for you? I've got vulkan on my machines, and have gotten imgui to work in vulkan based off of the examples and implementations.

since it was a sort of give away of the "CMake has too many ways to do the same thing and it appears nobody can agree on which way is best (depends on the person, depends on the month)" feeling you expressed.

c++ in general has the exact same problem. The solution is usually to not let the perfect become the enemy of the good and work iteratively - especially in the early phase. Start with a simple version, that covers just a few core scenarious and make sure you are reasonably happy with the way it can be used (a.k.a. the interface). Then iteratively improve it based on user feedback.

Also consider that breaking changes to the build system interface are usually much less disruptive than changes to the library itself, because there is "usually" only 1 or at most a handful of locations in the user project, where that interface is used. So there is less reason to be affraid to get stuck with a "bad" interface if the initial design is not ideal.

I guess what I'm trying to say: Assuming permission from @qix, you should probably just merge these changes and see what further issues / PRs pop up instead of delaying this indefinetly until no one feels there is even a point in working on cmake support at all.

I rebased this over latest, force-pushed so it's a clean PR, switched to C++11, etc. adjusted for moved backends, renamed sdl to sdl2 in various places.
There are still several things I cannot get to work on my Mac, as correct include paths are not pulled, it should call sdl2-config --cflags for SDL2 etc, but I'm simultaneously learning cmake and vscode..