GL/glext.h question

kmx
2010-03-02
2013-06-06
  •  kmx

    kmx - 2010-03-02

    Hi,

    first of all I am not an expert on OpenGL. I want just to know what are the reasons behind not having GL/glext.h in mingw-w64 headers.

    I know that MS SDK does not contain this header on the other hand mingw.org does and some packages tries to include it (on mingw-w64 unsuccessfully).

    Some maybe-relevant info I have found here: http://www.opengl.org/resources/faq/technical/extensions.htm. But I am still not sure about what is the right conclusion for mingw-w64.

    Thanks for any feedback.

    • kmx
     
  • Ozkan Sezer

    Ozkan Sezer - 2010-03-02

    I am not an ogl expert, either, although I happen to work on a few ogl projects. AFAIK, the reason glext.h (and wglext.h) are not included in mingw-w64 is that they are not part of Windows PSDK. However, the files provided by opengl.org (The Khronos Group) "seems" like they can be included:
    http://www.opengl.org/registry/api/glext.h
    http://www.opengl.org/registry/api/wglext.h
    Admins must decide what to do.

     
  •  kmx

    kmx - 2010-03-02

    Hi Ozkan,

    However, the files provided by opengl.org  (The Khronos Group) "seems" like they can be included:
    http://www.opengl.org/registry/api/glext.h
    http://www.opengl.org/registry/api/wglext.h

    Adding those two header files to include/GL dir did the trick (FYI I was compiling SDL bindings for perl).

    Can I ask some of the "decision makers" (nightstrike? kai?) whether it is possible to see these 2 files in mingw-w64 runtime?

    Thanks in advance.

    • kmx
     
  • NightStrike

    NightStrike - 2010-03-02

    If they aren't part of the PSDK, then we can't put them in there.  Mingw.org makes a lot of bad decisions in that area.

    We can, however, make them available via optional packages.  I'm assuming there's more than just these two files that fit that category.

    Then it just comes down to whether or not we want to have more files that we distribute that are controlled elsewhere.  I personally hate doing this, because it means we are never in synch with upstream.  Besides, it's 2010; duplicating code between projects should be a thing of the past.

    (Look at what we do now with the wine project and svn externals)

     
  • Ozkan Sezer

    Ozkan Sezer - 2010-03-02

    > If they aren't part of the PSDK, then we can't put them in there.  Mingw.org
    > makes a lot of bad decisions in that area.
    >
    > We can, however, make them available via optional packages.  I'm assuming there's
    > more than just these two files that fit that category.

    No, there is not. Those two, particularly glext.h, are
    commonly used one(s).

    > Then it just comes down to whether or not we want to have more files that we
    > distribute that are controlled elsewhere.  I personally hate doing this, because
    > it means we are never in synch with upstream.  Besides, it's 2010; duplicating
    > code between projects should be a thing of the past.
    >
    > (Look at what we do now with the wine project and svn externals)

    No arguments there.

     
  •  kmx

    kmx - 2010-03-02

    Nightstrike,

    I fully understand your point of view.

    To be clear I do not necessarily need GL/glext.h to become an integral part of mingw-w64, currently I would be happy if Ozkan will add them to his binary builds (which I am using) - for me it does not matter if he during building process takes them from mingw-w64 SVN or from other place. In the end I can of course download these 2 files to include/GL dir by myself.

    Anyway thanks for your feedback.

    I guess this thread will be useful for others dealing with mingw-w64 + GL/glext.h in the future.

    • kmx
     
  • Ozkan Sezer

    Ozkan Sezer - 2010-03-02

    > To be clear I do not necessarily need GL/glext.h to become an integral part
    > of mingw-w64, currently I would be happy if Ozkan will add them to his binary
    > builds (which I am using) - for me it does not matter if he during building

    Yes, I think I will.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks