Hmm this is a really murky modification. At this point we might as well modify our version of triangle to compile with .cpp and throw an exception directly. Providing an incomplete "triangle" lib where triexit is undefined can cause other problems down the line. E.g. what if another project have two components A and B, but A depends on libigl, and B only depends on triangle? Suddenly B is linked against triangle but doesn't provide implementation for triexit (which is in libigl). To make things more complicated libigl is currently a "header-only" library, but the implementation currently resides in a .cpp in the include/ folder, which is problematic.

Hmm this is a really murky modification. At this point we might as well modify our version of triangle to compile with .cpp and throw an exception directly. Providing an incomplete "triangle" lib where triexit is undefined can cause other problems down the line. E.g. what if another project have two components A and B, but A depends on libigl, and B only depends on triangle? Suddenly B is linked against triangle but doesn't provide implementation for triexit (which is in libigl).

Happy to accept a PR that does that change instead. This was meant to be a minimal change to libigl/triangle. I don't know what converting the whole thing to .cpp would entail (maybe that's what qnzhou/trianglelite; but it still just downloads the original triangle with this exit problem).

I'm not sure I 100% understand the A/B scenario. In this scenario, some component of the project is using triangle via libigl but not linking to libigl? Is this a scenario worth worrying about?

To make things more complicated libigl is currently a "header-only" library, but the implementation currently resides in a .cpp in the include/ folder, which is problematic.

This aspect should be fixed now.

Happy to accept a PR that does that change instead. This was meant to be a minimal change to libigl/triangle. I don't know what converting the whole thing to .cpp would entail (maybe that's what qnzhou/trianglelite; but it still just downloads the original triangle with this exit problem).

Actually you don't need to convert the whole file to .cpp. Simply add a file triexit.cpp in the libigl/triangle repo instead of adding your custom triexit function into libigl. Bonus point: you get to keep the TRIANGLE_CUSTOM_TRIEXIT define private to the triangle library, and it doesn't leak into client headers.

I'm not sure I 100% understand the A/B scenario. In this scenario, some component of the project is using triangle via libigl but not linking to libigl? Is this a scenario worth worrying about?

Yes, this happens all the time. If we put aside the triangle licensing issues for the sake of the argument, in a large product codebase you can have plenty of components using triangle directly, with other parts of the code using triangle through libigl (e.g. anyone who wants to use polyfem). Putting triexit() directly in libigl instead of triangle makes the triangle not self-contained anymore, and makes integration more problematic.

It is a small change to add the file triexit.cpp directly to our libigl/triangle repo instead, so I would prefer to do that for now.

Oh and yes qnzhou/trianglelite wouldn't solve this issue either, as it also depends on vanilla triangle. qnzhou/trianglelite is more like an alternative to the whole igl/triangle wrapper.

Btw I just tried renaming triangle.c into triangle.cpp it compiles perfectly fine out of the box, so to avoid the undefined behavior of throwing exceptions across C functions, I would rather switch triangle to .cpp directly.

Alright PR updated -- changes are much smaller now. Feel free to merge.