joemarshall commented on code in PR #37821:
URL: https://github.com/apache/arrow/pull/37821#discussion_r1402172399


##########
cpp/cmake_modules/SetupCxxFlags.cmake:
##########
@@ -702,3 +714,47 @@ if(MSVC)
     set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} 
${MSVC_LINKER_FLAGS}")
   endif()
 endif()
+
+if(CMAKE_SYSTEM_NAME STREQUAL "Emscripten")
+  # flags are:
+  # 1) We're using zlib from Emscripten ports
+  # 2) We are building library code
+  # 3) We force *everything* to build as position independent
+  # 4) And with support for C++ exceptions
+  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -sUSE_ZLIB=1  -fPIC -fexceptions")
+  # size_t is 32 bit in emscripten wasm32 - ignore conversion errors
+  # deprecated-literal-operator error is thrown in datetime (vendored lib in 
arrow)
+  set(CMAKE_CXX_FLAGS
+      "${CMAKE_CXX_FLAGS} -sUSE_ZLIB=1 -fPIC -fexceptions 
-Wno-error=shorten-64-to-32 -Wno-error=deprecated-literal-operator"
+  )
+
+  # flags for creating shared libraries (only used in pyarrow, because
+  # Emscripten builds libarrow as static)
+  # flags are:
+  # 1) Tell it to use zlib from Emscripten ports
+  # 2) Tell it to use javascript / webassembly 64 bit number support.
+  # 3) Tell it to build with support for C++ exceptions
+  # 4) Skip linker flags error which happens with -soname parameter
+  set(ARROW_EMSCRIPTEN_LINKER_FLAGS "-sWASM_BIGINT=1 -fexceptions 
-Wno-error=linkflags")
+  set(CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS
+      "-sSIDE_MODULE=1 ${ARROW_EMSCRIPTEN_LINKER_FLAGS}")
+  set(CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS
+      "-sSIDE_MODULE=1 ${ARROW_EMSCRIPTEN_LINKER_FLAGS}")
+  set(CMAKE_SHARED_LINKER_FLAGS "-sSIDE_MODULE=1 
${ARROW_EMSCRIPTEN_LINKER_FLAGS}")
+  if(ARROW_TESTING)
+    # flags for building test executables for use in node
+    set(CMAKE_EXE_LINKER_FLAGS
+        "${ARROW_EMSCRIPTEN_LINKER_FLAGS}  
-sERROR_ON_WASM_CHANGES_AFTER_LINK=1 -sALLOW_MEMORY_GROWTH -lnodefs.js 
-lnoderawfs.js --pre-js ${BUILD_SUPPORT_DIR}/emscripten-test-init.js"

Review Comment:
   Ah. It's because the tests are run in node.js  When you build in emscripten, 
you can pass a pre-run javascript which is run on startup of the test 
executable to setup the environment the tests are run in. Without this, 
ARROW_TEST_DATA and PARQUET_TEST_DATA aren't passed from the containing 
environment into the emscripten webassembly module. I don't really know why it 
doesn't pass things through by default - I suspect it is something to do with 
not wanting to pass things that are machine specific through to the webassembly 
virtual machine, but this needs to be done so that tests can see those 
environment variables.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to