Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup #969

Open
7 of 11 tasks
pca006132 opened this issue Oct 1, 2024 · 7 comments
Open
7 of 11 tasks

Cleanup #969

pca006132 opened this issue Oct 1, 2024 · 7 comments
Milestone

Comments

@pca006132
Copy link
Collaborator

pca006132 commented Oct 1, 2024

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.
@pca006132 pca006132 added this to the v3.0 milestone Oct 1, 2024
@elalish elalish mentioned this issue Oct 1, 2024
@starseeker
Copy link
Contributor

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

@pca006132
Copy link
Collaborator Author

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

@pca006132
Copy link
Collaborator Author

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

@starseeker
Copy link
Contributor

@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
Copy link
Collaborator Author

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

@starseeker
Copy link
Contributor

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
Copy link
Owner

elalish commented Oct 3, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants