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: https://github.com/elalish/manifold/blob/5e103931f1191eba8eb25d89b1039aa58a03e0db/CMakeLists.txt#L63-L65 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 https://github.com/elalish/manifold/discussions/520#discussioncomment-6693526 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.