glew.h undefines APIENTRY and also prevents gl.h from being included by defining its include guard. This means that APIENTRY is not defined within osmesa.h which usually relies on gl.h to define it.
If APIENTRY is not defined when importing osmesa.h, we define it temporarily and then undefine when done. This is similar to the existing workaround for GLAPI which likely exists for the same reason as above. It seems that only clang fails to compile when APIENTRY is not defined, but it seems like it should be defined regardless of compiler or it ends up in the source file. With this change, I can build glew+osmesa for osx without issue.
I have taken a more conservative approach than GLAPI, defining and undefining when done. Maybe it's overkill, let me know.
I ran into this through the VTK project. So the testing I have done is with a VTK build using conda, it works fine.
glew.h undefines APIENTRY and also prevents gl.h from being included by defining its include guard. This means that APIENTRY is not defined within osmesa.h which usually relies on gl.h to define it.
If APIENTRY is not defined when importing osmesa.h, we define it temporarily and then undefine when done. This is similar to the existing workaround for GLAPI which likely exists for the same reason as above. It seems that only clang fails to compile when APIENTRY is not defined, but it seems like it should be defined regardless of compiler or it ends up in the source file. With this change, I can build glew+osmesa for osx without issue.
I have taken a more conservative approach than GLAPI, defining and undefining when done. Maybe it's overkill, let me know.
I ran into this through the VTK project. So the testing I have done is with a VTK build using conda, it works fine.
https://github.com/FoundationLLM/vtk-feedstock/blob/main/recipe/patches/define-apientry-osmesa-osx.patch