Trying to compile manifold on a Mac

[rsaccon]

I am using the latest patches for emscripten on an Intel Mac with MacOS 11.6.5. And I believe to have installed all the dependencies. For Mac there is no nvcc. Here is how far I got with the other options:

compiling for CPP:

cmake -DCMAKE_BUILD_TYPE=Release -DTHRUST_BACKEND=CPP .. && make

error:

...
In file included from /Users/robertosaccon/cAndCpp/manifold/collider/src/collider.cpp:15:
In file included from /Users/robertosaccon/cAndCpp/manifold/collider/include/collider.cuh:16:
/Users/robertosaccon/cAndCpp/manifold/utilities/include/sparse.cuh:16:10: fatal error: 'thrust/binary_search.h' file not found
#include <thrust/binary_search.h>
         ^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [collider/CMakeFiles/collider.dir/src/collider.cpp.o] Error 1
make[1]: *** [collider/CMakeFiles/collider.dir/all] Error 2
make: *** [all] Error 2

and my attempt for emscripten:

emcmake cmake -DCMAKE_BUILD_TYPE=Release .. && emmake make

error:

...
CMake Error at third_party/CMakeLists.txt:8 (add_subdirectory):
  add_subdirectory given source "assimp" which is not an existing directory.


CMake Error at tools/CMakeLists.txt:16 (find_package):
  By not providing "FindCGAL.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "CGAL", but
  CMake did not find one.

  Could not find a package configuration file provided by "CGAL" with any of
  the following names:

    CGALConfig.cmake
    cgal-config.cmake

  Add the installation prefix of "CGAL" to CMAKE_PREFIX_PATH or set
  "CGAL_DIR" to a directory containing one of the above files.  If "CGAL"
  provides a separate development package or SDK, be sure it has been
  installed.


-- Configuring incomplete, errors occurred!

I have CGAL installed (with brew). Any advice on how to build it on a Mac ?

[elalish]

I haven't even tried this yet myself, so @pca006132 is the most likely to know. I'd guess you're missing some of the steps that Github Actions is doing under the hood: https://github.com/elalish/manifold/pull/103/files#diff-723c1253d0c94075d3d7c80504b08943c02209f016433937ccf803a3ca6eb5fe

[pca006132]

Sorry the PR has been force-pushed multiple times today, as it is only working on my computer locally but not in the CI. This should now be fixed. The emscripten build should not require CGAL, so I guess you are using an old version.

There are several things to check:

1. Are you using the latest version from the PR? I have force-pushed it multiple times today so yours may be outdated.
2. Did you clone the git submodules? The emscripten build needs those submodules to work.
3. Did you apply the patch to assimp? The patch removes the -Werror compiler flag in assimp, because there is an unused variable in their code which causes build failure. Command: patch third_party/assimp/code/CMakeLists.txt < assimp.diff

[rsaccon]

Thanks for the responses. I tried again with latest version and the emscripten build worked. I look forward to play around with it !

The CPP build failed again, this time at the google-test linking:

[ 20%] Linking CXX static library libgtest.a
cd /Users/robertosaccon/cAndCpp/manifold-emscripten/buildCPP/third_party/google_test/googletest-build/googlemock/gtest && /usr/local/Cellar/cmake/3.21.3_1/bin/cmake -P CMakeFiles/gtest.dir/cmake_clean_target.cmake
cd /Users/robertosaccon/cAndCpp/manifold-emscripten/buildCPP/third_party/google_test/googletest-build/googlemock/gtest && /usr/local/Cellar/cmake/3.21.3_1/bin/cmake -E cmake_link_script CMakeFiles/gtest.dir/link.txt --verbose=1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar qc libgtest.a CMakeFiles/gtest.dir/src/gtest-all.cc.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib libgtest.a
[ 20%] Built target gtest
make: *** [all] Error 2

[pca006132]

Nice, let me know when you can integrate it with some JS stuff! I guess it can now load and export 3D models via assimp, but I haven't really tried that out yet.

Not sure why the CPP build fails, can you try to get some more verbose output for it?

[rsaccon]

I checked again the CPP build log and there is a compile error as well:

[ 11%] Building CXX object meshIO/CMakeFiles/meshIO.dir/src/meshIO.cpp.o
cd /Users/robertosaccon/cAndCpp/manifold-emscripten/buildCPP/meshIO && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++  -I/Users/robertosaccon/cAndCpp/manifold-emscripten/meshIO/include -I/Users/robertosaccon/cAndCpp/manifold-emscripten/third_party/thrust -I/Users/robertosaccon/cAndCpp/manifold-emscripten/third_party/glm -I/Users/robertosaccon/cAndCpp/manifold-emscripten/utilities/include -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -mmacosx-version-min=11.6 -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CPP -std=gnu++14 -MD -MT meshIO/CMakeFiles/meshIO.dir/src/meshIO.cpp.o -MF CMakeFiles/meshIO.dir/src/meshIO.cpp.o.d -o CMakeFiles/meshIO.dir/src/meshIO.cpp.o -c /Users/robertosaccon/cAndCpp/manifold-emscripten/meshIO/src/meshIO.cpp
/Users/robertosaccon/cAndCpp/manifold-emscripten/meshIO/src/meshIO.cpp:19:10: fatal error: 'assimp/Exporter.hpp' file not found
#include "assimp/Exporter.hpp"
         ^~~~~~~~~~~~~~~~~~~~~
1 error generated.

the thing is, buildWASM/third_party/assimp exists, but there is no buildCPP/third_party/assimp

(base) robertosaccon@MacBook-Pro buildCPP % ls -al  third_party 
total 24
drwxr-xr-x   7 robertosaccon  staff   224 May  6 04:06 .
drwxr-xr-x  16 robertosaccon  staff   512 May  6 04:16 ..
drwxr-xr-x   4 robertosaccon  staff   128 May  6 04:06 CMakeFiles
-rw-r--r--   1 robertosaccon  staff  4813 May  6 04:06 Makefile
-rw-r--r--   1 robertosaccon  staff  1638 May  6 04:06 cmake_install.cmake
drwxr-xr-x   8 robertosaccon  staff   256 May  6 04:06 google_test
drwxr-xr-x   6 robertosaccon  staff   192 May  6 04:06 graphlite

[pca006132]

Indeed, the build script will not build assimp if the target is not for emscripten. I thought that users can just use their own local installation. Perhaps we should build that also.

[elalish]

Indeed, the build script will not build assimp if the target is not for emscripten. I thought that users can just use their own local installation. Perhaps we should build that also.

Yeah, I left a comment to that effect in your PR. Keeping the build process consistent will probably make our lives easier. You also mentioned here that you'd like to make gtest a submodule as well. That also seems reasonable given all the other submodules you've added. Honestly, maybe graphlite should be a submodule too instead of just being copied in. Seems more legit. I know some people are anti-submodule, but I can't remember the reasons at the moment; hopefully they don't apply to this.

[rsaccon]

In my case, I have assimp (Version 5.2.3) installed via common MacOS package manager brew. So with current situation, am I supposed to set some environment variable so my local assimp can be found ?

[pca006132]

Before I update the PR, you can try the following patch:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ac27861..b344ffe 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -12,13 +12,13 @@ set(CMAKE_VERBOSE_MAKEFILE ON)
 set(THRUST_BACKEND "CUDA" CACHE STRING
     "Thrust backend, either \"CUDA\", \"OMP\" or \"CPP\"(single-threaded)"
 )
+set(ASSIMP_INC_DIR 
+    ${PROJECT_SOURCE_DIR}/third_party/assimp/include
+    ${CMAKE_BINARY_DIR}/third_party/assimp/include)
 if(EMSCRIPTEN)
     message("Building for Emscripten")
     set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -sALLOW_MEMORY_GROWTH=1)
     set(THRUST_BACKEND "CPP")
-    set(ASSIMP_INC_DIR 
-        ${PROJECT_SOURCE_DIR}/third_party/assimp/include
-        ${CMAKE_BINARY_DIR}/third_party/assimp/include)
 endif()
 set_property(CACHE THRUST_BACKEND PROPERTY STRINGS CUDA OMP CPP)
 
diff --git a/third_party/CMakeLists.txt b/third_party/CMakeLists.txt
index 26877ee..44c3372 100644
--- a/third_party/CMakeLists.txt
+++ b/third_party/CMakeLists.txt
@@ -1,11 +1,9 @@
 add_subdirectory(google_test)
 add_subdirectory(graphlite)
 
-if(EMSCRIPTEN)
-    set(BUILD_SHARED_LIBS off)
-    set(ASSIMP_BUILD_ASSIMP_TOOLS off)
-    set(ASSIMP_BUILD_TESTS off)
-    add_subdirectory(assimp)
-endif()
+set(BUILD_SHARED_LIBS off)
+set(ASSIMP_BUILD_ASSIMP_TOOLS off)
+set(ASSIMP_BUILD_TESTS off)
+add_subdirectory(assimp)

Regarding the MacOS package problem, I am not sure why can't CMake find the include path for assimp. Perhaps the one you installed does not contain header files, i.e. not a dev package? Anyway we should switch to building with submodules so this should not be a problem later.

[rsaccon]

With the patch applied, it successfully built. But one of the CPP tests failed:

[ RUN      ] Manifold.Determinism
/Users/robertosaccon/cAndCpp/manifold-emscripten/test/mesh_test.cpp:156: Failure
Expected equality of these values:
  num_overlaps
    Which is: 229439
  229611
[  FAILED  ] Manifold.Determinism (98 ms)

About the package problem, there is only one assimp package available with that package manager, so for Mac users it is probably better assimp gets locally built.

Anyway, I am very excited to play around with manifold. I will try to access the lib from python, i guess manifold-cad is currently the best example how it can be done.
EDITED: Uups, python bindings in the work by pca006132, but there is a comment there: "not working yet"

[pca006132]

iirc the determinism one failing is expected.

For python binding, manifold-cad is just something I rushed in an afternoon for quick testing (I want to see if this can replace openscad for faster builds), so it is not a proper python binding. You can have a look at https://github.com/pca006132/manifold/tree/pybind11 , which is a proper python binding with numpy support, but you may have to rebase with the emscripten branch first to update the build script.

The branch is using this lazy union: #100 which triggers #102, so it is still a WIP.

[rsaccon]

yeah, I just saw it, thanks a lot, will try to dive into it ...

[rsaccon]

now we can close this as well, will open later a new issue regarding python bindings