Until now, I have been simply working off SDL2/OpenGL on Linux. However, now I am trying to implement multiple platform layers and have seem to hit a problem.
(For the record, I am using the "OS Virtualization" approach that Casey mentioned as it seemed appropriate. If it turns out that it is causing all the trouble, I don't have a problem in switching to what Casey actually used.)
Let's take an exaggerated example: say I want to write a platform layer for Linux that will be compatible with maximum number of machines. So, I use Xlib and OpenGL; however, possibly in future, Wayland might become the BIG thing and might not have proper X11 emulation. So, now I have Xlib/OpenGL and Wayland/OpenGL. And Ubuntu is working on Mir, so Mir/OpenGL is in there too. But X can be used on MacOS too (I think) so let's add a Xlib/OpenGL-MacVersion. And when we are at it, Cocoa/OpenGL, Cocoa/Metal and Xlib/Metal don't sound bad either. On the other hand, Windows support OpenGL; so, Win32/OpenGL is in mix along with Win32/D3D and potentially Win32/Vulkan. And of course, we need OpenGL 2.0/3.3/4.4, DX 9/11/12 and please save me!
What I tried to do was compile a "partial-platform layer" with each of these APIs into DLLs and the idea was that I could interop them. However, after much headbutting, that doesn't seem to be working as each of these combination might have a slightly different interface (example: some of these APIs might want window handles, some might not, some might want special data/context extracted using window handles, etc). So, the question is: how can I manage this kind of chaos? I could simply reduce the support to one API pair per OS but are there any better solutions to this problem?