GLFW 3.4 / External platform

I was looking at the 3.4 release and the concept of platform that was introduced. Having worked on the GLFW3 emscripten implementation, I am not too sure how I would implement the glfwGetPlatform() API since none of the defines make sense: the code runs in the browser so the platform is “web” or “emscripten”?

I understand that this platform is not part of the official distribution, but GLFW in the browser is a reality… Would it make sense to add a new define for this purpose?

// one of these?
#define GLFW_PLATFORM_WEB        0x00060006

I think that would make sense, and personally I would choose GLFW_PLATFORM_EMSCRIPTEN.

Is the right approach to submit a pull request on GitHub?

The official GLFW repository cannot add this platform define because it doesn’t have the emscripten platform, and I don’t think we can take on an emscripten platform at the moment.

So you should just add this define to your own project: GitHub - pongasoft/emscripten-glfw: This project is an emscripten port of glfw written in C++ for the web/webassembly platform #wasm

What we can do is reserve that platform ID for Emscripten, even if it isn’t currently part of the official repository.

@dougbinks I know I can add this define to my project (and the emscripten built-in project) and I would be fine doing that, but what if in GLFW 3.5, this value is used for some other platform officially supported by GLFW?

As @elmindreda suggested, it would be great if there was a platform ID reserved for Emscripten.

I suppose an alternative would be to have an official platform ID for “other” (GLFW_PLATFORM_OTHER) which could be returned by other platforms not part of the official distribution.

A reserved platform Id for Emscripten is a good idea, though we have to be careful to ensure people don’t think this means they can use GLFW with Emscripten out of the box.

If we go that route I can see some other unofficial platforms wanting to add their defines. If we didn’t want to open up that capability then GLFW_PLATFORM_OTHER is a decent alternative. It might be best to offer a range of defines for ports which support multiple platforms (GLFW_PLATFORM_OTHER_START to GLFW_PLATFORM_OTHER_MAX or similar).

I am up for whatever solution makes the most sense for GLFW. Just let me know which way you want to go.

Our current plan is to reserve a define and add a comment in the header that this is reserved.

For example:

/*! @addtogroup init
 *  @{ */
/*! @brief Hint value that enables automatic platform selection.
 *  Hint value for @ref GLFW_PLATFORM that enables automatic platform selection.
#define GLFW_ANY_PLATFORM           0x00060000
#define GLFW_PLATFORM_WIN32         0x00060001
#define GLFW_PLATFORM_COCOA         0x00060002
#define GLFW_PLATFORM_WAYLAND       0x00060003
#define GLFW_PLATFORM_X11           0x00060004
#define GLFW_PLATFORM_NULL          0x00060005
/*! @} */

/* Reserved platform define for external Emscripten port: 0x00060006
 * See 

So you should be able to go ahead and use 0x00060006.

Does that work for you?

Absolutely. This is awesome and would work perfectly!

I am also planning to add support for this new (platform) API to the built-in (javascript) implementations that comes packaged with emscripten since I did some work on it recently. Although they are different implementation (one is C++, the other javascript), they represent the same platform. So maybe the comments could be:

/* Reserved platform define for external Emscripten ports: 0x00060006
 * See
 * See

But either way, knowing that this value is reserved is enough for me to move forward with implementation! Thank you so much.