Emscripten build

[stephomi]

Can we add an option to skip the wasm bindings when targeting EMSCRIPTEN? Or an option to skip the nixos thing.

For my wasm integration I used to do something like:

add_compile_definitions(_LIBCUDACXX_HAS_THREAD_API_EXTERNAL)
set(EMSCRIPTEN 0)
add_subdirectory(lib/manifold/)
set(EMSCRIPTEN 1)

But now the build fails because of nixos thing:

manifold/CMakeLists.txt

Lines 63 to 65 in 5e10393

	# for nixos
	set(CMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES
	${CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES})

If EMSCRIPTEN is 1, then the wasm bindings fail (don't really want to investigate why, as I don't use it)

Other tiny question: Is D_LIBCUDACXX_HAS_THREAD_API_CUDA doing something for wasm?

[pca006132]

Sure, we can add a MANIFOLD_JSBIND option. Also it is a bit interesting that the implicit include directory will cause compilation error, I was not expecting it. Maybe you can make a PR to make the wasm bindings optional? (we want to enable MANIFOLD_JSBIND for emscripten by default, but can be overridden by the user.)

IIRC D_LIBCUDACXX_HAS_THREAD_API_CUDA is required for solving some compilation error with thrust, and is needed for wasm.

Also, you can try to use the latest tbb as it supports emscripten now. See #520 (comment) for the patch. We did not enable it right now because the emscripten worker file does not support modules yet.

[elalish]

Why would you want to target Emscripten without the WASM bindings? What would your output be?

[stephomi]

Because I’m integrating manifold in a c++ code base.
The output is simply .a, it works just fine, I don’t need any js bindings.

(By the way, there is now a collider.a, etc for every folder except of just a single manifold.a, not sure if done on purpose, bu I now need to link 5/6 lib in Xcode instead of a single one).

[pca006132]

(By the way, there is now a collider.a, etc for every folder except of just a single manifold.a, not sure if done on purpose, bu I now need to link 5/6 lib in Xcode instead of a single one).

No this is not on purpose. Can you show the output of tree? FYI this is my output:

├── src
│   ├── CMakeFiles
│   ├── cmake_install.cmake
│   ├── collider
│   │   ├── CMakeFiles
│   │   │   └── collider.dir
│   │   │       └── src
│   │   │           └── collider.cpp.o
│   │   ├── cmake_install.cmake
│   │   └── libcollider.a
│   ├── cross_section
│   │   ├── CMakeFiles
│   │   │   └── cross_section.dir
│   │   │       └── src
│   │   │           └── cross_section.cpp.o
│   │   ├── cmake_install.cmake
│   │   └── libcross_section.a
│   ├── manifold
│   │   ├── CMakeFiles
│   │   │   └── manifold.dir
│   │   │       └── src
│   │   │           ├── boolean3.cpp.o
│   │   │           ├── boolean_result.cpp.o
│   │   │           ├── constructors.cpp.o
│   │   │           ├── csg_tree.cpp.o
│   │   │           ├── edge_op.cpp.o
│   │   │           ├── face_op.cpp.o
│   │   │           ├── impl.cpp.o
│   │   │           ├── manifold.cpp.o
│   │   │           ├── offset.cpp.o
│   │   │           ├── properties.cpp.o
│   │   │           ├── smoothing.cpp.o
│   │   │           └── sort.cpp.o
│   │   ├── cmake_install.cmake
│   │   └── libmanifold.a
│   ├── polygon
│   │   ├── CMakeFiles
│   │   │   └── polygon.dir
│   │   │       └── src
│   │   │           └── polygon.cpp.o
│   │   ├── cmake_install.cmake
│   │   └── libpolygon.a
│   ├── sdf
│   │   ├── CMakeFiles
│   │   │   └── sdf.dir
│   │   │       └── src
│   │   │           └── sdf.cpp.o
│   │   ├── cmake_install.cmake
│   │   └── libsdf.a

[elalish]

Oh, I see, so Manifold is part of a larger project that is also being compiled to WASM. Makes sense.

@pca006132 I think you're showing exactly what he's saying: separate .a files for each folder, rather than one top-level, right? We do intentionally separate the library in case you just want pieces of it. Still, maybe making a bundled version would also be useful? PRs welcome, but we do need to consider how much testing any additional permutations would require.

[pca006132]

hmmm, I consider each directory to be a package of its own, so the current behavior is the correct behavior. I did not check, but I think the libmanifold.a file should contain the content of libcollider.a when it is built as a static library.

[stephomi]

Embree does it the same way and I always found it a bit annoying. Blue embree, red manifold (libsdf not required though).
It's not that important though.

[pca006132]

We can bundle those libraries into a single dynamic library. E.g.

$ ldd src/manifold/libmanifold.so
	linux-vdso.so.1 (0x00007ffe3c18a000)
	libClipper2.so.1 => /home/pca006132/code/manifold/build/src/third_party/clipper2/CPP/libClipper2.so.1 (0x00007fce25859000)
	libquickhull.so => /home/pca006132/code/manifold/build/src/third_party/libquickhull.so (0x00007fce256d1000)
	libm.so.6 => /nix/store/9la894yvmmksqlapd4v16wvxpaw3rg70-glibc-2.37-8/lib/libm.so.6 (0x00007fce25f4c000)
	libtbb.so.2 => /nix/store/cb3g0kxj80whxvmp9mq92r4hfdq8c8xa-tbb-2020.3/lib/libtbb.so.2 (0x00007fce2568b000)
	libgcc_s.so.1 => /nix/store/yyfqqmdx3s7w088dqy0qhyqd0gjcvm2k-gcc-12.3.0-libgcc/lib/libgcc_s.so.1 (0x00007fce2566a000)
	libc.so.6 => /nix/store/9la894yvmmksqlapd4v16wvxpaw3rg70-glibc-2.37-8/lib/libc.so.6 (0x00007fce25484000)
	/nix/store/9la894yvmmksqlapd4v16wvxpaw3rg70-glibc-2.37-8/lib64/ld-linux-x86-64.so.2 (0x00007fce2602e000)
	libdl.so.2 => /nix/store/9la894yvmmksqlapd4v16wvxpaw3rg70-glibc-2.37-8/lib/libdl.so.2 (0x00007fce25f45000)
	librt.so.1 => /nix/store/9la894yvmmksqlapd4v16wvxpaw3rg70-glibc-2.37-8/lib/librt.so.1 (0x00007fce25f40000)
	libstdc++.so.6 => /nix/store/ci51zm09w9skb92zkc5x9x2vr1pkb0h6-gcc-12.3.0-lib/lib/libstdc++.so.6 (0x00007fce25200000)
	libpthread.so.0 => /nix/store/9la894yvmmksqlapd4v16wvxpaw3rg70-glibc-2.37-8/lib/libpthread.so.0 (0x00007fce2547d000)

However, I don't know how to ask CMake to not generate those archive files. I don't think they matter anyway as we don't have to distribute them.

[stephomi]

To clarify, the behaviour changed because OBJECT has been removed when adding the library, e.g: add_library(collider OBJECT).
Just wondering if it was on purpose or not.

[pca006132]

To clarify, the behaviour changed because OBJECT has been removed when adding the library, e.g: add_library(collider OBJECT). Just wondering if it was on purpose or not.

OK I checked, OBJECT will mess up shared library builds. There are ways to get around this but I don't think it is worth the hassle.