build: cmake support, examples included

[tamaskenez]

You can test the build simply by running ./cmake-testbuild.sh. It builds imgui + opengl examples.

I tested it on Windows (msysgit prompt) and Linux. Requires CMake >= 2.8.12.

Rest of the commit msg:

• cmakelist for imgui, installs config module
• cmakelist for opengl and opengl3 examples
• cmake-testbuild.sh to test cmake build
• tested on windows, linux

[ocornut]

Thanks. There's two part in that.

1. imgui
   Unfortunately it's not ok to have a cmakelist for ImGui (library) itself.

• It's presence detract from the principle than ImGui doesn't need a build system and sends a wrong message. The library is designed to lower the bar to integration and merely "suggesting" that the library needs to be built as a library defeat part of that expectation. As you know building libraries under Windows is often a pain. Being very clear with having no build files send the message that you can just drop the files in your application. So we cannot have a cmake file in the root folder, not there should be an out/ folder.
• Building ImGui as a lib is really not recommended as it prevents people from using the facilities in imconfig.h in particular IM_VEC2_CLASS_EXTRA which is REALLY useful. If people are used to use a .lib they will tend to bypass all those features which is a really undesirable thing,

2. examples
   But it's ok and desirable to make better builds for the Examples applications! Those can freely compile imgui.cpp along with them. Could you rework those cmakelist files to be standalone (include imgui as a .cpp and perhaps gl3w as well) ?

Thanks a lot!

[tamaskenez]

Okay, I see your points. Let's discuss this a bit more. Maybe we can get to a point which would satisfy both you and the cmake-people.

• it's no problem to move the imgui CMakeLists.txt into a /cmake or /contrib/cmake subdir to hide it
• I can modify the imgui cmake project to create a library target which contains no .lib, only a set of source files. So it would be the same as adding the imgui files manually to a user project. The imconfig.h features would work as expected.
• building libraries, or more exactly, using libraries is a pain, unless one uses some tool (e.g. CMake) to make it easy. It's great that imgui can be integrated so easily, but this method, that is, adding a dependency to a project by actually copying the source files is more like a workaround and does not go well with git and CI workflows.
• I don't understand your comment on the out directory. It's just a temporary build directory, not part of the repository. It could be /tmp/imgui-test or anything but that's not portable.

I think using CMake allows us to include imgui (or any other deps) by simply adding 2 lines to a project file so there's no pain any more. Let me know your thoughts about this. Of course I will understand if you still don't want imgui CMakelist.

[extrawurst]

On Wed, Jul 1, 2015 at 5:27 PM, Tamas Kenez [email protected]
wrote:

Okay, I see your points. Let's discuss this a bit more. Maybe we can get
to a point which would satisfy both you and the cmake-people.

• it's no problem to move the imgui CMakeLists.txt into a /cmake or
  /contrib/cmake subdir to hide it
• I can modify the imgui cmake project to create a library target
  which contains no .lib, only a set of source files. So it would be the
  same as adding the imgui files manually to a user project. The
  imconfig.h features would work as expected.
• building libraries, or more exactly, using libraries is a pain,
  unless one uses some tool (e.g. CMake) to make it easy. It's great that
  imgui can be integrated so easily, but this method, that is, adding a
  dependency to a project by actually copying the source files is more like a
  workaround and does not go well with git and CI workflows.

actually it works totally great with git using submodules. you can pick
what version of imgui you wanna use and update as you whish. simply place
the submodule whereever external libs are and there you go. configure your
projects cmake to use that folder in the build too and there you go.

• I don't understand your comment on the out directory. It's just a
  temporary build directory, not part of the repository. It could be
  /tmp/imgui-test or anything but that's not portable.

I think using CMake allows us to include imgui (or any other deps) by
simply adding 2 lines to a project file so there's no pain any more. Let me
know your thoughts about this. Of course I will understand if you still
don't want imgui CMakelist.

—
Reply to this email directly or view it on GitHub
#255 (comment).

[tamaskenez]

@extrawurst: thanks for the suggestion, but no. I would skip discussing submodules here, but I'm glad to answer in an issue on my fork.

[tamaskenez]

I added some new commits. The important changes:

• cmake-related files moved from root to /cmake/
• imgui used from sources, not as a compiled library (works with cmake 2.8.12 or later)
• user imconfig.h supported
• added a new example: imconfig_example
• documentation added/updated, emphasing that cmake is optional

[tamaskenez]

@ocornut: I understand that what you really need is to substitute the examples' Makefiles with cmake projects. Doing exactly what the Makefile does.

While that's possible to do, I'd rather not do it. Reason: I would happily violate any DRY principle if I gain something. In this case I don't see we gain anything by repeating the list of imgui files and compile flags in each consuming project. Copying the files or using a costly workaround (submodule) is also pure minus. So I would stick with the established build-install-link workflow since I see no drawbacks of it here. Using imgui in the user project is super-easy and concise, see the docs in my latest commit.

Anyway, feel free to use the cmake files I wrote for the examples to convert them to no-lib-style, if you like.

And yes, congrats for the great library!

[ocornut]

Thanks for the update!

building libraries, or more exactly, using libraries is a pain, unless one uses some tool (e.g. CMake) to make it easy.

Yes but the problem is that there are many such tools - and every one of those tool is still alien to a majority of the population.

Copying the files or using a costly workaround (submodule) is also pure minus.

I don't understand this sentence. For the files to appear in your folder you'd need to do either a copy either check them out via git.

adding a dependency to a project by actually copying the source files is more like a workaround and does not go well with git and CI workflows.

I don't understand either or have to disagree. Yes it is a workaround around the sad state of building and dependencies in the C++ and Windows world. But it's still the best way and I don't see how copying a few files interfer with git or CI workflow or adding a cmake file makes a difference. Right now for me it is a net strategic mistake to introduce a cmake/ folder and a dozen more files.

In your setup could you host the imgui cmakelist on your side? so e.g. you'd have imgui/cmakefile and actual vanilla code in imgui/imgui/.

I would like to have a better / neater build system for the examples in particular because I want more examples in (for various framework GLUT, SDL, Allegro, etc.) so there's a lot to do here but the reality is that I may not have time to look into those things. They are really long and tedious to test. Examples and building related PR are unfortunately the ones that lives the longest here. Right now I probably wouldn't mind having cmakelist for the examples if they referred to imgui.cpp directly but it'll probably take me a while to sort it out and the PR . Will do eventually!

[adam4813]

In my ci setup I have imgui as a submodule and add the source files to be built inside my game. So there isn't an issue with submodule git and ci by doing it that way.

[hypernewbie]

Have you considered making this a header-only library? That's what I'm doing; I'm renaming the .cpp file to .inl and including it in my UI source.

[ocornut]

@hypernewbie it's already a little too big really, I am considering splitting the .cpp into two or three files possibly (see #219).. That says it would be trivial to create a wrapper but as you said you can include the .cpp file as well.

[tamaskenez]

@ocornut:

You (and @adam4813) don't understand what my problem is with your workarounds in git/CI settings. Of course, copying files and submodules do work with git and CI. Just like global variables and backward gotos work fine in a c++ setting. It just gets unmanageable at a scale and most importantly, there's a better way. In my CI setup I have 100 repos building 20 end targets for 4 products for 5 platforms. Things working fine for a single developer with a single project get very inconvenient at this scale.

What you guys suggest and use (copy or submodule) are real, nice workarounds. But I don't understand that why are you keep promoting workarounds when the real solution is available? You keep saying things like "sad state of building and dependencies in the C++ and Windows world" and "in 2015 it is still a massive pain to create and maintain portable build files". Well, it's not. We have the tools. And it's not a novel thing, CMake is 16 years old and there are quite a few alternatives, too.

and every one of those tool is still alien to a majority of the population.

Well, then the best we can do to pick one and start promoting it in our repos to let them known about it, right?

In your setup could you host the imgui cmakelist on your side? so e.g. you'd have imgui/cmakefile and actual vanilla code in imgui/imgui/.

Yes, this can be a good compromise, I think I'll do it. And you know what: for this purpose submodules are perfect.

[tamaskenez]

@ocornut:

Would you accept just the small change to imgui.h? It's only to conditionally include imconfig.h:

#if !defined IMGUI_CONDITIONAL_IMCONFIG_H || defined IMGUI_INCLUDE_IMCONFIG_H
    #include "imconfig.h"       // User-editable configuration file
#endif

No pressure, if it doesn't fit your way I will patch the file on installation, that's also fine.

[ocornut]

Yes that's certainly possible as a first step. I haven't looked in detail but could it possibly be done with a single define? And your app-side cmakelist would undef the default define?

[tamaskenez]

Of course, a single define like this was my first thought:

#ifdef IMGUI_INCLUDE_IMCONFIG_H
    #include "imconfig.h"       // User-editable configuration file
#endif

The only reason for the double-define was backward compatibility. Existing projects that use non-empty imconfig.h do not define IMGUI_INCLUDE_IMCONFIG_H.
If that's not an issue then the single-define is better.

[ocornut]

No I meant define that behave like the DISABLE one you added. Your cmake integration would define it and your user code that assume a imconfig.h file would undef it.

(Backward compatibility needs to be preserved here)

[tamaskenez]

The problem is that not only user code but also imgui.cpp which includes imgui.h assumes imconfig.h. So only imgui.cpp or imgui.h could undef when imgui.cpp is compiled.

(It's also possible that I just don't get what you mean)

[ocornut]

Sorry i meant the user cmakefile code could undef it. (I don't know if you can undef from a cmake filr or not, following another cmake file doing a define)

[ocornut]

Disregard that. Even if it's possible in cmake it may not be possible in other build systems. So better off playing it safe and doing it with two defines.

[tamaskenez]

Thanks! Meanwhile I'm converting the cmake support to separate repo.

[ocornut]

Note I didn't use the exact same name as yours. I thought DISABLE was more in line with existing definitions. It's not really documented but anyone who wonders how to deal with editing imconfig.h will keeping files vanilla should stumble upon it.

[tamaskenez]

Okay, it seems to be working now: https://github.com/tamaskenez/imgui-cmake, the imgui repo as a submodule.

BTW I hear you're going to split up imgui.cpp. To illustrate the pros of imgui-as-a-library: for all the imgui-cmake users, for all the single one of them (me), this will be a no-op! :)

I'm closing this PR then.

[ocornut]

Cool. I'm happy to keep it PR open as reference for others and for myself when I get around to merge cmake stuff for examples at least.

[ocornut]

@tamaskenez Sorry for resurrecting this old topic.

I have added a IMGUI_USER_CONFIG which the user can set to a custom filename to include.

As far I as understand, I think we could retire the old IMGUI_DISABLE_INCLUDE_IMCONFIG_H and IMGUI_INCLUDE_IMCONFIG_H that we added int his topic.

So this block at the top of imgui.h:

// User-editable configuration files (edit stock imconfig.h or define IMGUI_USER_CONFIG to your own filename)
#ifdef IMGUI_USER_CONFIG
#include IMGUI_USER_CONFIG
#endif
#if !defined(IMGUI_DISABLE_INCLUDE_IMCONFIG_H) || defined(IMGUI_INCLUDE_IMCONFIG_H)
#include "imconfig.h"
#endif

Would become:

// User-editable configuration files (edit stock imconfig.h or define IMGUI_USER_CONFIG to your own filename)
#ifdef IMGUI_USER_CONFIG
#include IMGUI_USER_CONFIG
#endif
#include "imconfig.h"

It doesn't really hurt including an unmodified imconfig.h, and removing the extra define would reduce confusion. Where internet grepping I didn't find users of those defines apart from your project, and I can stick in #error directives to catch old code using them. Just wondered if you had an opinion on that.

[tamaskenez]

@ocornut, thanks for notifying me!
The change is fine with me, I don't use custom imconfig.h now.

(Actually I don't use the imgui-cmake repo any more, I'm building it in a slightly different way from this repo: cmakefied).

[ocornut]

Amusingly this was still open because of the suggestion to remove IMGUI_DISABLE_INCLUDE_IMCONFIG_H / IMGUI_INCLUDE_IMCONFIG_H, this is now done and closed.