glad OpenGL loader generator

[David]

glad - is an OpenGL loader (with experimental gles support, --api=gles2)
which is generated 1:1 from the OpenGL official spec
(https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/gl.xml).
It has at the moment a "backend" for three languages (frontend parses,
backend generates code, like constants and function pointers).

https://github.com/Dav1dde/glad

What are the advantages over e.g. Derelict?

* supports *every* opengl extension
* always up to date
* (basically) never incorrect bindings
* easy to maintain
* easy API, 3 functions
* allows you to use your own loader

And the more important:
* provides an easy way to check if extension X is loaded
`enforce(GL_EXT_Cg_shader)` (same works for OpenGL versions
`enforce(GL_VERSION_3_2)`)
* glad generates loaders exactly for your needs. If you only need a
OpenGL 3.2 core profile with two extensions, glad can generate exactly
this code. Making your binding small, without overhead.


What your code might look like with glad:

import glad.gl; // imports all constants and functions, including extensions
import glad.loader : gladInit, gladTerminate, gladLoadGL;
void main() {
    gladInit();
    scope(exit) gladTerminate();

    /* setup OpenGL context with e.g. glfw */

    auto glv = gladLoadGL();
    enforce(glv.major == 3 && glv.minor == 2);
    // or: enforce(GL_VERSION_3_2);
    enforce(GL_EXT_texture_filter_anisotropic);

    /* done, use OpenGL here */
}

gladInit() and gladTerminate() are not needed if you provide your own
loader, e.g. you use SDL:

void main() {
    /* setup OpenGL context with SDL */

    auto glv = gladLoadGL(&SDL_GL_GetProcAddress);
    enforce(glv.major == 3 && glv.minor == 2);

    /* done, use OpenGL here */
}

A fully blown OpenGL 4.4 compatability, all extensions loader:
https://github.com/Dav1dde/glad/tree/d
But I really recommend generating your own loader/binding for your exact
needs!

python main.py --generator=d
--extensions=GL_EXT_texture_filter_anisotropic --out-path=build


A example in C:
https://github.com/Dav1dde/glad/blob/master/example/c/simple.c (to show
glad is not rocket science!)



------- Slightly Offtopic, why Derelict/Dynamic linking is bad  --------

glad was mainly written to have an easy backend to support multiple
languages at a time, but also to get rid of Derelict as a dependency.

(warn: dynamic/static linking "rant")

OpenGL was the only reason I still used Derelict, now I could get rid of
another relativly big dependency. Don't get me wrong Derelict is great,
but dynamic loading isn't! Unfortunatly you have to dynamically load OpenGL.

Why is dynamic loading a problem?
Well static linking has several important advantages:
* slightly faster startup times
* easier to distribute
* no DLL hell like on windows! with all it's DLLs, it's a mess!
https://en.wikipedia.org/wiki/DLL_hell

If you depend on a system-wide installation of a library you get another
problem Windows might have a different DLL than Ubuntu a .so  or
Archlinux or Debian old stable, so you have to ship your DLLs with you
or depend on a specific version, which makes distribution a lot harder.

You might say, but on Windows, I can't statically link because dmc
doesn't really work (e.g. Makefiles not supporting DM Make), objconv
(another dependency next to the C compiler) etc... Well on Windows you
can still use an import library. Which brings us to the next advantage.
You don't need two separate librarys for one and the same binding (one
which works like a C-Header and one with a ton of function pointers and
loader code attached).