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)
- gcc14 build failure HOT 7
- Triangulation issue: Zebra HOT 3
- BSD compiler error HOT 1
- Another Zebra Triangulation issue HOT 6
- Port for vcpkg HOT 9
- use size_t whenever possible
- Auto generated python stubs inconsistent with cpp API HOT 14
- Rust bindings HOT 22
- Build error with Emscripten 3.1.61 HOT 1
- Debug MSVC build error HOT 8
- NumTri returns uint32_t, while array uses size_t (like uint64_t or int64_t) HOT 3
- Warning as errors HOT 4
- operator""_z returns unsigned and is in the global scope
- Is there a guide to getting it run with Vite using SvelteKit HOT 1
- Some crashes on invalid data. HOT 8
- Building Python package from PyPI sdist dies with CMake configuration errors HOT 3
- offset a convex manifold HOT 13
- Oriented bounding box HOT 1
- OpenSCAD fails to build without CrossSection: no member named ‘ToPolygons’ HOT 13
- Know is Manifold::Boolean(xxx, OpType::Subtract) operation has actually done something (changed source manifold) HOT 1
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.