Cleanup

[pca006132]

A list of cleanup to do before v3.0.

• https://github.com/elalish/manifold/blob/master/RELEASE_CHECKLIST.md
• Cleanup .vscode/launch.json.
• Move the public header install logic to the main cmake file?
• Remove the single mesh file in extras/Thingi10K/raw_meshes.
• Organize extras, e.g. move things related to hull testing to its own folder, add readme to explain the use of each file.
• format.sh format cmake.
• Remove .gitmodules.
• Update readme about the clang-format version requirement.
• Workaround errors when compiling for iOS #944 by adding ignore flags.
• Try to make fuzzing work again.
• Check the documentation to make sure things are up-to-date.

[starseeker]

For the formatting of cmake, did you have a preferred solution in mind?

[pca006132]

No, maybe https://github.com/cheshirekow/cmake_format? I haven't yet tried it though.

[pca006132]

@elalish for fuzzing, I encountered google/fuzztest#1022, not sure how to fix it.

[starseeker]

@pca006132 It's not cleanup, but were we going to decide what to do about glm in the public headers et. al. prior to 3.0? Didn't know if that should be added to the 3.0 milestone...

[pca006132]

Yes, but not sure if I should convert the discussion into issue, the discussion is very long and has multiple threads.

[starseeker]

I guess @elalish should weigh in, but it seems like there's maybe the following two issues at play?

1. Avoid exposure of glm types in public headers (seems like some form of generic-to-glm casting is currently the front runner for solving that one, combined with flattening any "vector of vecs" type structures?)
2. Deciding what (if anything) to do about positioning the public API to be ready to (most likely optionally) avoid data copying of user supplied inputs (while recognizing that Manifold is still and for the foreseeable future will be using quite a bit of memory internally.)

[elalish]

Yeah, 1) sounds like the right approach for v3.0. I'm comfortable crossing the 2) bridge when we come to it. We did a similar thing we when we built MeshGL parallel to Mesh without a breaking change - we can do that again if necessary. Unless someone has a great idea for a simple thing we should do right now, I'm going to ignore it.

[pca006132]

Currently, about half of our files in extras do not work:

1. minimize_testcase.cpp does not parse the current polygon dump format.
2. perf_test_cgal.cpp does not compile (we should remove it anyway)
3. test_hull_performance.cpp does not compile.

I'm thinking if we should fix these before the release, or it is fine to just leave them as is for now. These are just for our internal use only anyway.

[elalish]

Yeah, I wouldn't call anything in extras a priority. Might be good to remove perf_test_cgal at least so there's one less optional dependency to confuse people.