link against system library instead of building from source

[pca006132]

I'm looking into updating this to the latest manifold version. While the C API has not changed much, it seems that there is a lot of code for compiling manifold that has to be updated (it has been 2+ years now).

I'm thinking if it will be simpler to just link against a dynamic library, probably provided by the system. I am not familiar with OCaml, so not sure if that is the best way.

[geoffder]

Yes sorry everything of mine has fallen into disrepair since working to wrap my PhD and our daughter, sorry. Linking dynamically with a system package is possible, but I might be able to fix the existing static stuff if I spend some time with it (maybe it is a bit simpler now even). I may be able to set some time out for it soon now that we are coming up to winter break time at the Uni.

If I remember correctly from scanning github emails, Manifold no longer bothers with Cuda anymore right? So there are some lines handling that which can be done away with.

[geoffder]

I decided to poke around on it to see how much needs to be changed, and I've noticed that manifold is building clipper2 statically as libClipper2.a even when using -DBUILD_SHARED_LIBS=ON. I'm not 100% sure, but I think there is a reason why (which might still be relevant) I was building both static and shared libraries for the ocaml library ctypes which is handling the static linking of the bindings. When I get to it, I can test whether it is ok to only have the .a for clipper2. If not, is there a reason why manifold is still building that instead of an .so? @pca006132

[geoffder]

I have started a branch to work on this, currently I am blocked by the need for a shared libClipper2.so (it appears to be required by ctypes which is handling the C bindings).

[pca006132]

I think this is because we don't want to install libClipper.so to the system by ourselves. If you install a local clipper2, it should work.

[geoffder]

I'll play around with that, so far I hadn't been looking for specific archives in the system to grab for ctypes (instead all of them were compiled along with manifold), so I'll have to learn how to do that reliably. That seems like something that pkgconfig would be able to do for me, right now I only use it to check if tbb is available so I'll take a look at the API when I get a chance.

[geoffder]

Right, pkg-config just returns the flags required for compilation actually, I'm not sure if ctypes does anything to find the specified foreign_archives it needs in the system, or if I need to copy the files into the build directory (which would require me to know the paths of course). Not having the .so from manifold compiling clipper2 might be more of a pain than I thought if it doesn't.

[geoffder]

Ok, I need to figure out exactly what is needed and what isn't from my fiddling, but I've got it building and running the tests without linker errors as far as I can tell. Might be stuck with the system install of clipper2 which complicates the opam story a bit but it seems a worakable solution is possible.

[pca006132]

I see. Just let me know if there is anything I can help.

[geoffder]

I need to test more, but I might have made a mistake before trying too many things at once, since it seemed to build fine the last time I forced DMANIFOLD_USE_BUILTIN_CLIPPER2=ON. The internal bindings are pretty well updated now, next will be some sessions adding the new functions to the library and getting the API in order.