aboutsummaryrefslogtreecommitdiffstats
path: root/pugl/pugl_gl_backend.h
AgeCommit message (Collapse)AuthorFilesLines
2019-11-21Rename "backend" headersDavid Robillard1-32/+2
Working on Vulkan clarified what has always been slightly smelly about the design and organization here: not everything that is API specific is really in a "backend" (a PuglBackend). The concrete example is puglGetProcAddress(), which only makes sense for GL and is actually implemented in the "backend" files. Arguably puglGetContext() is also such a thing. So, rename the headers so they can be the place where API-specific things go in general, which happens to include a backend most of the time. The stub is a bit of an exception to this, but whatever. The includes look tidier this way. In place of the old headers are compatibility stubs that just emit a warning and include the new version, which will be maintained for a while.
2019-11-21Use consistent include guardsDavid Robillard1-3/+3
2019-11-18Move puglGetProcAddress to pugl_gl_backend.hDavid Robillard1-0/+11
This establishes a general pattern for backend-specific APIs, so that pugl.h doesn't become a mess. The name of these headers, and the definition of "backend", is a little fuzzy here, but it was before in reality anyway.
2019-07-29Completely separate backends from platform implementationDavid Robillard1-1/+10
This removes PuglContextType and allows the user to pass a backend directly. Normally this would come from one of the two accessors declared in the headers, but it would be possible to add backends without changing any of the existing code at all. Unfortunately, it is not possible to preserve backwards compatibility and achieve the ultimate goal of linking only to the required dependencies, so puglInitContextType() has just been removed.
2019-07-28Give backends general namesDavid Robillard1-0/+33
Towards making them opaque and exposing them to the user to decouple the core library from backends. The general names mean that it won't be possible to build multiple backends for one platform into the same binary, but that seems reasonable for now, and it will make things simpler without needing to add a bunch of dispatch code. That will still be possible if it's ever needed, though.