Automatically include the available gl loader header

[o-micron]

This change is additive and doesn't change the existing code.

It handles the case when we don't define any of these macros
{
IMGUI_IMPL_OPENGL_LOADER_GL3W,
IMGUI_IMPL_OPENGL_LOADER_GLEW,
IMGUI_IMPL_OPENGL_LOADER_GLAD,
IMGUI_IMPL_OPENGL_LOADER_CUSTOM
]

Using the __has_include clang extension, we can automatically know which header is available,
then we use it directly without predefined macros or anything, this fits naturally in the code without having to use gl3w or supply any macros ...

[corentin-plouet]

Note that __has_include is also a GCC extension, so it will work for that compiler too.

[o-micron]

@corentin-plouet oh year sure, it also is supported now on MSVC ... I just wanted to point out in case the extension isn't available everything will be fine still ... 😉

[ocornut]

Hello @o-micron,
Thanks for the PR.

Unfortunately I am not sure this is a desirable change to make.

Multiple headers may be available on the system, header availability doesn't mean that said loader is being used by the application. While in the examples's main.cpp case we rely on the same imgui_impl_opengl3.h header to decide on the loader, there's no reason for the user application to be using that same logic.

If a used tries to integrate the OpenGL back-end in their app which already uses and initialize glad, but the system has header files for glew.h then our back-end won't be using the same loader at the application (and app will crash as each loader requires initialization).

[o-micron]

I get your point, I also thought that would cause problems in case someone has multiple gl loader headers in the same project.

But why would I ever need to even put multiple gl loaders in the same project ?

I mean, I am not sure about other projects, but for me, I only use a single header, glew for example, and that's all I need, there is no reason to use glad for example while I already have glew ...

I thought I would add some automatic header inclusion in case the user didn't actually specify one, which is the default behaviour ... you have a single opengl header and you want imgui to use it without the need to actually define a macro to say that ...

I dunno ... I thought that would make things easier 😃

[ocornut]

I agree there's little point using multiple loaders simultaneously. That's the issue I highlighted... with this autodection now it is more likely to happen by accident.

You are also correct this is merely a default behavior, but this new potential issue it can create may be extremely difficult to understand for the end-user? Effectively it will manifest as a crash when calling GL functions in the renderer. Previously it would more likely fail to build and requires a loader to be selected explicitely. Now it will success to build but may lead to crash that will appear mysterious to the user. Tricky trade-off ?

(EDIT: typos)

[o-micron]

@ocornut yeah, I think if the user already is having multiple gl loaders in his/her project, then probably it would eventually crash with or without imgui ... his/her own code would eventually crash like you said ... that isn't imgui's problem in this case I guess ...

(EDIT)
Actually I think automatic header inclusion would fix the possibility of imgui including another gl loader header ? 🙂

[ocornut]

It's not a problem if the user is having multiple GL loader in their projects, it's a problem if the user have multiple GL loaders installed on their system (more likely) and the one they already use for their application doesn't match the one that those auto-detection statements will select.

[ocornut]

In addition there's not a single line of code in imgui_impl_opengl3.cpp which visibility depends on the currently selected GL loader, so the typical user who stumble on this issue will not understand if there's a loader mismatch...

We can minimize this issue by adding code under #ifdef blocks in ImGui_ImplOpenGL3_Init() to make it extra visible which GL loader header file is being used, and through e.g. syntax coloring help the user understand which one was used.

[o-micron]

Yeah, usually the user would have one and use one ... ?
I mean, yes, we could have more headers but not the ones initialized and so on ... But why would the user do that ? In that case, the user has to supply a macro, and everything would work as intended then .... but that isn't the default case ...

[ocornut]

I don't think you are understanding my point here.
Imagine that scenario:

1. User is using Glad in their application, they only know and care about Glad.
2. For some reason, they have a Glew package installed in their system.
3. With the auto-detection, the back-end will chose Glew and it will crash.
4. It will be very difficult for the user to understand what's going on. They'll get a crash in e.g. glGetIntegerv(), they'll look at the code and assume that the auto-detection found Glad. They don't know/care about Glew and won't assume that Glew was selected.

Previously, compilation would fail and force the user to select Glad. With the change, compilation will succeed and leave the user with a really hard to comprehend error.

[ocornut]

So my suggestion is to add this in the Init function:

(I have intentionally taken a screenshot of the code to show syntax coloring)
With this the user will be able to understand in the IDE and in the Debugger which loader has been selected. Which this and a few more comments I think we can merge your change.

[o-micron]

I think this also would fix this issue at compile time, leading to no surprises at runtime ...

// to avoid problem with non-clang compilers not having this macro.
    #if defined(__has_include)
        // check if the header exists, then automatically define the macros ..
        #if __has_include(<GL/glew.h>)
            #if __has_include(<glad/glad.h>)
                #error you have multiple headers in your system (GLEW + GLAD)
            #else
                #define IMGUI_IMPL_OPENGL_LOADER_GLEW
            #endif
        #elif __has_include(<glad/glad.h>)
            #if __has_include(<GL/glew.h>)
                 #error you have multiple headers in your system (GLEW + GLAD)
            #else
                #define IMGUI_IMPL_OPENGL_LOADER_GLAD
            #endif
        #else
            #define IMGUI_IMPL_OPENGL_LOADER_GL3W
        #endif
    #else
        #define IMGUI_IMPL_OPENGL_LOADER_GL3W
    #endif

[ocornut]

Merged now with a few changes in an extra commit (9769164), looks like our commits crossed..

I haven't used your second commit, partly because in theory we ought to check for more combinations (incl gl3w, in my change I am also explicitely using __has_include for gl3w) and I don't want to make that block in imgui_impl_opengl3.h too unwelcoming. The only reason this block is in the .h file is for the benefit of the example's main.cpp files but it should be required for the user.

I think with those changes we'll got a good solution in, what do you thnik?

[o-micron]

Cool, I was adding the dummy constructs you wanted to make it more visible ...
Great, I think it is robust enough now.

[ocornut]

Thanks for your help with this, great idea :)
Closing now!

Passing tests on CI machines too: https://travis-ci.com/ocornut/imgui