Skip to content
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

Closed
paleozogt opened this issue Apr 27, 2011 · 3 comments
Closed

emmaken.py needs to distinguish c from c++ #6

paleozogt opened this issue Apr 27, 2011 · 3 comments
Labels

Comments

@paleozogt
Copy link

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:

#include <stdio.h>

// C++ headers
#include <cmath>
#include <limits>

int helloworld(void) {
   printf("helloworld \n");
   return 0;
}

and CMakeLists.txt:

cmake_minimum_required(VERSION 2.8.3)

# these must be set *before* project()
if (EMSCRIPTEN)
    set(EMSCRIPTEN_TOOLS ${EMSCRIPTEN_HOME}/tools)
    SET(CMAKE_C_COMPILER          "${EMSCRIPTEN_TOOLS}/emmaken.py")
    SET(CMAKE_CXX_COMPILER        "${EMSCRIPTEN_TOOLS}/emmaken.py")
    SET(CMAKE_LINKER              "${EMSCRIPTEN_TOOLS}/emmaken.py")
    SET(CMAKE_CXX_LINKER          "${EMSCRIPTEN_TOOLS}/emmaken.py")
    SET(CMAKE_C_LINK_EXECUTABLE   "${EMSCRIPTEN_TOOLS}/emmaken.py")
    SET(CMAKE_CXX_LINK_EXECUTABLE "${EMSCRIPTEN_TOOLS}/emmaken.py")
endif(EMSCRIPTEN)

project(helloworld)

# these must be set *after* project()
if (EMSCRIPTEN)
    SET(CMAKE_AR                  "${EMSCRIPTEN_TOOLS}/emmaken.py")
    SET(CMAKE_RANLIB              "${EMSCRIPTEN_TOOLS}/emmaken.py")
endif(EMSCRIPTEN)

# list of sources
set(SRCS helloworld.c)

# compile all files as C++, no matter their extension
set_source_files_properties( ${SRCS} PROPERTIES LANGUAGE CXX )

# make a lib
add_library(helloworld ${SRCS})

has this output:

$ cmake .. -DEMSCRIPTEN=1 -DEMSCRIPTEN_HOME=/home/vail/Development/emscripten; make VERBOSE=1
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Check for working C compiler: /home/vail/Development/emscripten/tools/emmaken.py
-- Check for working C compiler: /home/vail/Development/emscripten/tools/emmaken.py -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /home/vail/Development/emscripten/tools/emmaken.py
-- Check for working CXX compiler: /home/vail/Development/emscripten/tools/emmaken.py -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/vail/Development/helloworld/.build-js
/usr/bin/cmake -H/home/vail/Development/helloworld -B/home/vail/Development/helloworld/.build-js --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/vail/Development/helloworld/.build-js/CMakeFiles /home/vail/Development/helloworld/.build-js/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/vail/Development/helloworld/.build-js'
make -f CMakeFiles/helloworld.dir/build.make CMakeFiles/helloworld.dir/depend
make[2]: Entering directory `/home/vail/Development/helloworld/.build-js'
cd /home/vail/Development/helloworld/.build-js && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/vail/Development/helloworld /home/vail/Development/helloworld /home/vail/Development/helloworld/.build-js /home/vail/Development/helloworld/.build-js /home/vail/Development/helloworld/.build-js/CMakeFiles/helloworld.dir/DependInfo.cmake --color=
Dependee "/home/vail/Development/helloworld/.build-js/CMakeFiles/helloworld.dir/DependInfo.cmake" is newer than depender "/home/vail/Development/helloworld/.build-js/CMakeFiles/helloworld.dir/depend.internal".
Dependee "/home/vail/Development/helloworld/.build-js/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/home/vail/Development/helloworld/.build-js/CMakeFiles/helloworld.dir/depend.internal".
Scanning dependencies of target helloworld
make[2]: Leaving directory `/home/vail/Development/helloworld/.build-js'
make -f CMakeFiles/helloworld.dir/build.make CMakeFiles/helloworld.dir/build
make[2]: Entering directory `/home/vail/Development/helloworld/.build-js'
/usr/bin/cmake -E cmake_progress_report /home/vail/Development/helloworld/.build-js/CMakeFiles 1
[100%] Building CXX object CMakeFiles/helloworld.dir/helloworld.c.o
/home/vail/Development/emscripten/tools/emmaken.py     -o CMakeFiles/helloworld.dir/helloworld.c.o -c /home/vail/Development/helloworld/helloworld.c
emmaken.py:  /home/vail/Development/emscripten/tools/emmaken.py -o CMakeFiles/helloworld.dir/helloworld.c.o -c /home/vail/Development/helloworld/helloworld.c
emmaken.py:  /home/vail/Development/emscripten/tools/emmaken.py -o CMakeFiles/helloworld.dir/helloworld.c.o -c /home/vail/Development/helloworld/helloworld.c
Running: /home/vail/Development/llvm-gcc-4.2-2.9.source/cbuild/install/bin/llvm-gcc -o CMakeFiles/helloworld.dir/helloworld.c.o -c /home/vail/Development/helloworld/helloworld.c -m32 -U__i386__ -U__x86_64__ -U__SSE__ -UX87_DOUBLE_ROUNDING -UHAVE_GCC_ASM_FOR_X87 -emit-llvm -c
/home/vail/Development/helloworld/helloworld.c:1:17: error: cmath: No such file or directory
/home/vail/Development/helloworld/helloworld.c:2:18: error: limits: No such file or directory
make[2]: *** [CMakeFiles/helloworld.dir/helloworld.c.o] Error 1
make[2]: Leaving directory `/home/vail/Development/helloworld/.build-js'
make[1]: *** [CMakeFiles/helloworld.dir/all] Error 2
make[1]: Leaving directory `/home/vail/Development/helloworld/.build-js'
make: *** [all] Error 2
@paleozogt
Copy link
Author

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.

@kripken
Copy link
Member

kripken commented Apr 27, 2011

The attachments work fine over here.

From your log, I suspect the problem is

error: cmath: No such file or directory

etc. That is, missing header files or improper include directories set up?

@kripken
Copy link
Member

kripken commented Apr 27, 2011

IRC discussion cleared up my misunderstanding.

Fixed in 85cba40

@kripken kripken closed this as completed Apr 27, 2011
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 .
@juj juj added the CMake label Jul 28, 2014
tlively pushed a commit to tlively/emscripten that referenced this issue Mar 23, 2022
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
Labels
Projects
None yet
Development

No branches or pull requests

3 participants