-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
emmaken.py needs to distinguish c from c++ #6
Labels
Comments
I think the solution here is to have some kind of c++/c shim file. emmaken_cxx.py and emmaken_c.py that call through to the underlying emmaken.py script. |
The attachments work fine over here. From your log, I suspect the problem is
etc. That is, missing header files or improper include directories set up? |
IRC discussion cleared up my misunderstanding. Fixed in 85cba40 |
juj
referenced
this issue
in juj/emscripten
Sep 25, 2013
…or vertex attribute stride and offset presented in WebGL section 6.4 are satisfied in user code. See http://www.khronos.org/registry/webgl/specs/latest/1.0/#6.4 .
Closed
tlively
pushed a commit
to tlively/emscripten
that referenced
this issue
Mar 23, 2022
Fixed statfs64 bug
steveisok
pushed a commit
to steveisok/emscripten
that referenced
this issue
Sep 18, 2023
…upstream behaviour (emscripten-core#6) * Strip out files to better match what we ship in our Python package
sbc100
pushed a commit
that referenced
this issue
Aug 2, 2024
This contains 2 new versions with the following release notes for the underlying project: #### 3.4.0.20240731 - 2024-07-31 - Added `emscripten_glfw_get_clipboard_string` the C version of `emscripten::glfw3::GetClipboardString` to retrieve the clipboard asynchronously - Added a helper class `emscripten::glfw3::FutureClipboardString` to greatly simplify the more frequent use-cases - `GetClipboardString::value()` now returns the internal clipboard in case of error, instead of throwing exception - Added `optimizationLevel` option to the emscripten port #### 3.4.0.20240727 - 2024-07-27 - Introduced C++ API (namespace `emscripten::glfw3`) included with `GLFW3/emscripten_glfw3.h`: - provides a more correct API with sensible defaults (ex: `std::string_view` / `std::optional<std::string_view>` vs `char const *` which may or may not be `nullptr`) - allow for C++ only API (ex: `std::future`) - the C API is still available if you would rather stick to it - Implemented `emscripten::glfw3::GetClipboardString` which provides a way of fetching the global clipboard in a browser environment (`glfwGetClipboardString` is not the right API due to the asynchronous nature of the underlying platform API). - The cursor position is no longer clamped to the window size, and as a result, can have negative values or values greater than the window size. Note that GLFW implements a similar behavior on the macOS desktop platform. - Implemented `glfwSetWindowPosCallback` - Added support for GLFW Window Attribute `GLFW_HOVERED` - Fixed [#6](pongasoft/emscripten-glfw#6): _`emscripten_glfw_make_canvas_resizable` does not clean up properly_. - Fixed an issue with opacity: when using opacity, the handle is not working unless its z-index is higher than the canvas z-index
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With CMake its possible to compile .c files as C++. This is an unfortunate yet common practice in large, legacy codebases. emmaken.py uses the extension to figure out which compiler it needs to use, but this fails with .c files that are really c++.
For example, using helloworld.c:
and CMakeLists.txt:
has this output:
The text was updated successfully, but these errors were encountered: