Hello Gerrit, I still would like to get an answer from you. Let me rephrase my point:
> 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. and > 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? and finally > It would be fine if we could found some common ground on that issue, > however. So I don't see what could be wrong by working on complete and the most recent content of the gl specification. Best, Johannes ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
