Adding CMake build

[AndySomogyi]

Hey @ocornut, how would you feel about adding a CMake build system?

I'm evaluating using imgui vs. nanogui to build simple interfaces for my glew based apps. Nanogui is not all that nano, it has a large number of dependencies, including eigen which conflicts with another library that's also using eigen.

I'd be OK with writing a CMake based build to imgui, would you accept it as a pull?

That way, I could reference imgui in my git and my project, and CMake would automatically take care if as a subproject.

[ocornut]

The idea is that imgui just needs you to include .cpp files in your project, this is the point of having no dependency. Just copy the .cpp files inside your project. If you really want to create a cmake file for imgui then feel free it to do locally.

I wouldn't accept any file or folder related to build systems in the root folder, it would scare more people off than it would be useful.

If you grep for CMake or CMakefile in this github you'll probably find references to other cmake files.

[matteomandelli]

I have the following dir structure

project <dir>
    CMakeFile
    3rdParty <dir>
        ImGui <dir>
            ...

and the following in my CMakeFile.

include_directories("3rdParty/imgui/")
file(
	GLOB 3rdPartyImGui
		"3rdParty/imgui/imgui.cpp"
		"3rdParty/imgui/imgui_draw.cpp"
		"3rdParty/imgui/imgui_demo.cpp"
		"3rdParty/imgui/*.h"
)
source_group(3rdParty\\ImGui FILES ${3rdPartyImGui})

Hope this helps.

[ocornut]

Note that you are encouraged to modify imconfig.h to add conversion to your own math types, whereas treating the imgui/ folder as its own library doesn't generally encourage you to modify this file.

[AndySomogyi]

One of my main goals is to have a git submodule linked to the original imgui, so I can pull it whenever, and NOT have to merge anything, I want to have the imgui 100% match the 'official' repo.

What would work best, is if imgui had a CMakeFiles.txt inside it, that way, it could have a git submodule point to it, and then literally just reference it in my CMakeLists.

I've sort of done this, outside of the imgui repo, take a look at this CMakeLists.txt file.

I have it build imgui as a static lib, but you'll notice how I set the interface include and link dependencies.

That means that any other CMakeModule literally just has to do an add_target_library(myproject, imgui), and this automatically adds all the include paths and processor definitions to the new target that's being built. I have glfw as a public dependency of imgui, so all targets then automatically get the glfw include and library dependencies added.

I still need to clean this CMakeLists.txt up a bit, but the general idea is that projects can just add git submodules, and if each submodule has a CMakeLists.txt, then the CMake in the top level project automatically resolves dependencies and adds the headers, links, etc. to dependent projects.

https://github.com/AndySomogyi/PositionBasedDynamics/tree/master/extern

[ocornut]

I've sort of done this, outside of the imgui repo, take a look at this CMakeLists.txt file.

What's the problem with leaving the cmake files in the parent folder?

That means that any other CMakeModule literally just has to do an add_target_library(myproject, imgui), and this automatically adds all the include paths and processor definitions to the new target that's being built. I have glfw as a public dependency of imgui, so all targets then automatically get the glfw include and library dependencies added.
then the CMake in the top level project automatically resolves dependencies and adds the headers, links, etc. to dependent projects.

imgui itself doesn't depend on anything, it doesn't need extra linking or include paths, so I am not sure I understand this. imgui_impl_glfw.cpp does but if you are using glfw you are already setting those paths?

One of my main goals is to have a git submodule linked to the original imgui, so I can pull it whenever, and NOT have to merge anything, I want to have the imgui 100% match the 'official' repo.

As posted above, your approach will prevent you from easily modifying imconfig.h, unless you create your own fork and merge there with your imconfig.h. That would work!

[AndySomogyi]

I definitely don't want to touch imconfig.h, as if there are any upstream changes, then I have to merge them together. What I think would be cleaner is if the build system let you specify whatever needs to go into the config, that way, no source ever has to be touched.

I still haven't worked out all the details, but basically what I'd like is to have a way so people can make a new project, then just add dependencies as git submodule, and simply reference them with their CMake. This works pretty well with a number of projects such as glfw. Then each dependency that uses other dependencies simply references them internally via an target_link_library(myproj, dependency), and this takes care of all the header paths, link paths, etc...

Modern CMake is really nice this way, and it also generates Xcode, Eclipse, and Visual Studio projects.

What I'm doing now is I have my CMake create a single 'imgui' library (technically it's just an object file, but it's treated like a lib). This single lib packages up the imgui, imgui_glfw, and sets up a glfw dependency. I suppose I could make it more modular in that 'imgui' would be separate from 'imgui_glfw', and imgui_glfw would then have both an imgui and glfw dependency. Then clients could then just simply reference the 'imgui_glfw' lib, and this would take care of setting the the paths and so forth.

[ocornut]

I definitely don't want to touch imconfig.h, as if there are any upstream changes, then I have to merge them together.

I don't think you are taking this from the right angle. You are a user of imgui presumably because it is helpful to you. You could consider the feature it has to offer instead of limiting yourself because of the limitation of how you'd like to use your build-system and source control. Build systems and source controls are a mean to an end, ideally they shouldn't constraint you.

Those settings imconfig.h involves compile-time change of data structures and thus are part of the core library. Branching the git to include your imconfig.h mods and merging upstream to your branch would be appropriate and probably the most natural way to doing it IMHO.

What I think would be cleaner is if the build system let you specify whatever needs to go into the config, that way, no source ever has to be touched.

There's no trivial way that I know of to allow those compile-time changes apart from removing the imconfig.h from the repo and requiring the user to serve it from another directory, which requiring extra logistic for everyone and imho cause more confusion that anything.

imgui very intentionally doesn't rely on a build system because they are causing problems to many users. Shipping .cpp is a way to say "you can build with anything, anywhere, even on non-standard platforms or esoteric build systems", which game developers are often relying on when shipping on many platforms.

Adding a few .cpp files to your existing project should be a trivial 2 seconds operation on your side if you are already using cmake.

If you have specific constraints (shipping imgui+glfw to a client in the form of a library) or just want to create new problems so you can solve them, up to you. I understand what you are aiming to do, it's a very common desire, I'm just saying this is not something that should be handled as part of the core imgui library. You can create this cmakefile on your side.

Arguably the examples app should use a better build systems to ease maintenance, this is different topic that would require more work to sort out (maintaining examples that compile/links/run everywhere tends to be more work than maintaining the library, regardless of the build systems used).