Hello Gerrit, I'm really happy to hear from you.
On 28.09.2016 21:02, Gerrit Voß wrote: > sorry for taking so long to answer, it's currently silly season ;) I hope that things settle for you. :-) > currently I pull on demand and split the defines and functions. That was what I tried to avoid. Currently I'm working with recent stuff of the GL specification and it is annoying to always add the missing things piece by piece, forgetting this piece and that piece or doing it wrong somehow in the first place. That does always leads to a compile link cycles which take their time. So I thought that it would be perfect to have all symbols and prototypes of the most recent GL spec at hand. What I did was merely to split the prototypes and renamed them to the osgGL... convention. Now, that has worked perfect to me. IMHO, if you need the gl... prototypes under different conditions, that could also be mapped into my scheme. > The reason behind that is that on Linux (where I spend most of my time) I > can directly build against OpenGL 4.x libraries. OSGGLFuncProtos.h > is build in a way that I can switch between the window based extension > mechanism and direct linking. > > What I usually do if I need newer functionality which is not > inside either OSGGLExt.h or OSGGLFuncProtos.h depends on the system > I'm on. On Linux I just define GL_GLEXT_PROTOTYPES before anything else > and am done with it. > On Windows I use glew (set > OSG_ENABLE_GL_INCLUDE_GLEW to TRUE and make sure glew is available). > The only trick is that one has to intialize glew at the right time. > > Once I'm done testing I pull the required things over to OSGGLExt and > OSGGLFuncProtos. > > The problem with just dumping things in there was the following: > > In file included > from > /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGGLDefineMapper.h:47:0, > > from > /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGGLDefineMapper.cpp:45: > /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGGLEXT.h:1523:18: > error: conflicting declaration ‘typedef uint64_t GLuint64EXT’ > typedef uint64_t GLuint64EXT; > ^ > In file included from /usr/include/GL/gl.h:1630:0, > > from /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGGL.h:71, > > from > /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGBaseTypeTraits.h:49, > > from > /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGBaseTypes.h:837, > > from > /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGSingletonHolder.h:45, > > from > /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGGLDefineMapper.h:46, > > from > /home/gerrit/Projects/OpenSG/svn/OpenSG/Source/Base/Base/OSGGLDefineMapper.cpp:45: > /usr/include/GL/glext.h:3901:28: note: previous declaration as ‘typedef > long long unsigned int GLuint64EXT’ > typedef unsigned long long GLuint64EXT; > ... I see, but isn't it the problem of the non spec conforming content of the /usr/include/GL/glext.h file? If you compile against that file you can't use any of the extensions that use GLuint64EXT types in its signature or you would have compatibility issues. Actually, I'm puzzled why /usr/include/GL/glext.h is included at all? Where is the #include statement for that file? > > that's how I bumped into it and that's why I like it a little bit more > controlled, and also more nicely formatted ;) Ok, I agree on that, but probably I define control slightly differently than you. ;-) Formatting is another issue, that could be enhanced in my approach so. It would be fine if we could found some common ground on that issue, however. Best, Johannes ------------------------------------------------------------------------------ _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
