Comments (10)
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.
from manifold.
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.
from manifold.
Why would you want to target Emscripten without the WASM bindings? What would your output be?
from manifold.
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).
from manifold.
(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
from manifold.
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.
from manifold.
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.
from manifold.
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.
from manifold.
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.
from manifold.
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.
from manifold.
Related Issues (20)
- Python created object reports as non-manifold. HOT 3
- Watertightness of Mesh with an Edge Shared by 4 Faces
- vertex halfedge iterator
- Manifold 2.4.5 release tar.gz is incomplete HOT 3
- Vec out of Range HOT 8
- Python binding needs two import call HOT 4
- Manifold Decompose doesn't preserve vertex properties HOT 4
- memory leak when TBB and PSTL is enabled HOT 27
- Triangulate bug: Two separate polygons HOT 5
- [Question] robust geometric predicates, polygon triangulation
- Warning comparison of integer expressions of different signedness
- Modularize Manifold HOT 25
- Build without exceptions HOT 3
- Remove Thrust HOT 19
- How to figure out required size of mem in the C-API? HOT 1
- Crash in Project() HOT 4
- gcc14 build failure HOT 7
- Triangulation issue: Zebra HOT 3
- BSD compiler error HOT 1
- Another Zebra Triangulation issue HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from manifold.