Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GLES Header Name and directory #353

Closed
WildRackoon opened this issue Jan 17, 2022 · 4 comments
Closed

GLES Header Name and directory #353

WildRackoon opened this issue Jan 17, 2022 · 4 comments

Comments

@WildRackoon
Copy link
Contributor

WildRackoon commented Jan 17, 2022

It looks like in several projects I encountered, the GLES headers have a somewhat standard form:
#include <GLES2/gl2.h> or #include <GLES3/gl3.h>

Instead of the custom #include <glad/gles2.h> and #include <glad/gles3.h>

ImGui is an example where this can be problematic: it is loader agnostic and relies on those See GL3/GLES Backend.

Its a minor issue indeed, but do you have an opinion on this ?

@Dav1dde
Copy link
Owner

Dav1dde commented Jan 17, 2022

Where do you see the issue, just because the naming convention is different and it should be <GLES2/glad.h>? Or do you think glad should generate <GLES2/gl2.h> as well?

  1. <GLES2/glad.h>: I think all glad headers should be correctly namespaced as such, which also helps keep things organized in a project.
  2. That's problematic, those headers are not actually fully compatible, glad provides mostly the same functionality, but e.g. pre processor macros aren't implemented, also glad defines glSymbol as #define glSymbol glad_glSymbol which is also a difference. Usage is also different, with glad you're supposed to call the loader function(s).

Also if the backend supports loading of the symbols (like imgui does with imgl3wInit), glad isn't actually required and doesn't add any benefit.

PS: With glad2 you can generate a header only library which you can freely rename without needing to update other files.

@WildRackoon
Copy link
Contributor Author

I think glad should optionaly be able to generate <GLESx/glx.h> headers for convenience (cmake option ?), I understand the compatibility issues, but you can probably let people use this at their own risks ...

I only encountered this 'niche' renaming requirement with this ImGUI's imgl3wInit() that doesn't seem customizable to the point of loading a GLES implementation only, and my glad context is not 'in-sync' with it without a fix.

@Dav1dde
Copy link
Owner

Dav1dde commented Jan 17, 2022

I have thought about "post processing" steps before, e.g. changing the glad prefix to something custom, but usually not many people need this and can be done in a < 5 lines shell script (mv and sed, or just sed in the case of changing the prefix). Which is the reason I never added it.

So if I understand that correctly you want to modify your build environment in a way that imgui picks up the glad instead of the system headers?

@WildRackoon
Copy link
Contributor Author

Just like you described I use a "5 lines script", its actually within my project's CMakeLists:

  target_compile_options(IMGUI PUBLIC "-DIMGUI_IMPL_OPENGL_ES2")
  get_target_property(MY_GLAD_BINARY_DIR glad BINARY_DIR )
  set(MY_GLAD_GLES_HEADER "${MY_GLAD_BINARY_DIR}/gladsources/glad/include/glad/gles2.h" ) #WIP Do reliable find
  set(MY_GLAD_GLES_MOCK_DIR  "${MY_GLAD_BINARY_DIR}/gladsources/glad/include/GLES2")
  set(MY_GLAD_GLES_MOCK_FILE "${MY_GLAD_GLES_MOCK_DIR}/gl2.h" )
  add_custom_command(
    OUTPUT ${MY_GLAD_GLES_MOCK_FILE}
    COMMAND ${CMAKE_COMMAND} -E echo  "Copy ${MY_GLAD_GLES_HEADER} to ${MY_GLAD_GLES_MOCK_FILE}="
    COMMAND ${CMAKE_COMMAND} -E copy ${MY_GLAD_GLES_HEADER} ${MY_GLAD_GLES_MOCK_FILE}
    DEPENDS ${MY_GLAD_GLES_HEADER}
  )
  add_custom_target(MY_IMGUI_GLAD_FIX DEPENDS "${MY_GLAD_GLES_MOCK_FILE}")
  add_dependencies( IMGUI MY_IMGUI_GLAD_FIX )

Indeed if not many people need this, no need to worry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants