I just came across this post when reading on the Haxe Google groups, and it looks very cool and promising. I think this could be useful for making optimisations for the C++ targets for OpenFL, and potentially also make the code-base cleaner and easier to work with, without the need to compile the SDL yourself.
I don’t know enough about SDL to be able to contribute, but I would love to see some feedback regarding this and whether or not linc could be useful for OpenFL?
I think it is a good idea
I want to make sure that things work on a broad number of platforms. While the linc approach works for C++, it will fail for Neko or Node.js, and other runtime environments.
Hugh mentioned “CFFI Prime” that might give us similar benefits, while also supporting Neko and other runtimes. While keeping our current compatibility, I would love to see performance improvements in our bindings.
Lime is also made to abstract away some of the lowest-level code, switching to GLFW instead of SDL2, or mapping to wxWidgets or Qt, or console platforms, does not change the Lime API so I don’t know that we should rely too heavily on one backend
That’s interesting. The problem with that, I think, is that people who want to make games using Direct3D won’t get that with Lime, since you’re working purely on OpenGL at the point, so I would personally still use SDL for that reason. I understand OpenGL is getting better, but considering Windows 10 is out alongside DirectX 12, keeping the SDL layer there only seems logical.
Maybe use separate flags when targeting windows, where you get the choice to use SDL or GLFW backends to distinguish between DirectX and OpenGL. Just throwing out suggestions. I’m no expert 
I’m thinking of looking into using externs for creating an abstraction for the entire wxWidgets library in Haxe, it would take a very long time to complete because the library is huge, but I think it would be cool nonetheless. And that, of course, would be using something similar to linc.
GLFW and SDL2 are alternatives for some of the same goals, but they might support different features. Since SDL2 is already working (and supports iOS and Android), I don’t think there is an argument for using GLFW instead (which uses OpenGL as well) but its an example 
When you use HXCPP, compilation is long, and requires a compiler. HXCPP tends to be best for users, though, in terms of performance, but for development (or for cross-desktop building) it might not always be the best choice. Flexible bindings give us the opportunity to use virtual machines, such as Neko and Node.js today, or perhaps other options (such as Java) if there was a benefit.
So I am talking about finding a solution that maximizes the benefit on C++, while also providing compatibility for other environments, a “best of both worlds” approach 
please forget all that hardware-buerocratics … i need mingW for my microsoft-windmill
and if GLFW or all libs did problem (to grow) -> branch
and name it -> “GL” only