Add FreeBSD Support

[remdrivet]

Is your feature request related to a problem? Please describe.
Please consider adding FreeBSD

I have successfully built and run Rayforge natively on FreeBSD. The application starts normally, loads its built-in addons, and initializes the PyOpenGL 3D canvas. It runs with the system Python installation and can be packaged as a normal FreeBSD package without requiring a virtual environment at runtime.

Tested environment
FreeBSD 16.0-CURRENT amd64
Python 3.12.14
Rust 1.97.1
Rayforge revision: 3e42dcb6
Rayforge version: 1.11.0.post12+git.3e42-book6
Raygeo: 1.50.0
GTK: 4.20.4
libadwaita: 1.8.5.1
libvips: 8.18.5

Additional context
Changes required:
Link clipper2c-sys against libc++ on FreeBSD
clipper2c-sys/build.rs does not currently handle FreeBSD. FreeBSD uses libc++, so the following target branch was required:
diff:
"- ("macos", _) | ("ios", _) => println!("cargo:rustc-link-lib=dylib=c++"),
"+ ("freebsd", _) | ("macos", _) | ("ios", _) => { println!("cargo:rustc-link-lib=dylib=c++") }
This problem may have to be handled by clipper2c-sys tho?

Avoid Raygeo's mimalloc global allocator on FreeBSD
After building Raygeo, importing the extension initially failed with:
"ImportError: raygeo.abi3.so: No space available for static Thread Local Storage"

The working solution was to disable Raygeo's mimalloc global allocator on FreeBSD using: "#[cfg(not(target_os = "freebsd"))]".
FreeBSD then uses Rust's system allocator, while other platforms retain the existing mimalloc behavior.
After rebuilding, Raygeo imported successfully and Rayforge started normally.

Use packaged PyMuPDF on FreeBSD
FreeBSD's py312-pymupdf 1.27.2.2 package works sufficiently for Rayforge to start. This may require relaxing Rayforge's exact PyMuPDF version pin on FreeBSD.

I will continue testing Rayforge with a laser engraver and see if I hit any other problems but its running at the moment fine after these "fixes".

[knipknap]

Thank you for this outstanding report — this is exactly the kind of detail that makes supporting a new platform tractable. I've checked each of the three items against the current code, and I can confirm your diagnosis on all of them.

You guessed right about the C++ linking issue: it does belong in the third-party wrapper, not in our code. The polygon clipping library that the geometry engine uses is bundled through a small upstream helper crate, and its build script only knows how to link the C++ standard library on Linux, macOS, iOS, Android and Windows — for anything else it deliberately stops with an "unimplemented" error. Grouping FreeBSD with macOS, as you did, is the correct fix, because FreeBSD's system C++ library is libc++ just like on Apple platforms. I'll submit a patch to the wrapper's maintainer, and once that is released the geometry engine will pick it up automatically. Until then, your local patch is the way to go.

The allocator problem is ours to fix in the geometry engine, and your solution is exactly what I would have done. The engine installs a custom memory allocator that keeps memory usage noticeably lower on long-running jobs. That allocator needs a small piece of per-thread storage, and FreeBSD only reserves that space when a program starts — so when Python loads the engine afterwards, there is none left, which produces the confusing "no space available for static Thread Local Storage" error you hit. Skipping the custom allocator on FreeBSD and using the system one, as you proposed, is the clean answer. The only cost is slightly higher memory use in some workloads; behavior is otherwise identical. I'll include that change in the next geometry engine release.

The PyMuPDF pin is easy to relax. The exact version exists to keep the development environment reproducible, but it currently also applies to source installs, which is unnecessarily strict for packagers. I'll turn it into a minimum version so the FreeBSD package works as-is.

One note for your engraver testing: camera discovery has dedicated backends for Linux and Windows, and falls back to a generic scan elsewhere — I'm curious whether that finds your device under webcamd. Everything else, like machine connections, job planning and G-code export, is platform-independent. Please do report anything else you run into, and thanks again for the porting work — having FreeBSD supported would be great.

[remdrivet]

Nice to see, i have hit a couple of more issues. Sadly my machine is a low-end hobby machine with no camera. I would love to test one out tho. "Normal" webcams do work so unless there is some specific hardware, I cant test, it should be doable on FreeBSD as well.

Rayforge's USB-port detection only recognized the usual Linux device names:
USB_PORT_MARKERS = ("ttyUSB", "ttyACM")

FreeBSD names USB callout serial devices /dev/cuaU0, /dev/cuaU1, and so on. PySerial returned the port correctly, but Rayforge filtered it out because cuaU was not recognized as a USB serial-port marker.

Fix:
USB_PORT_MARKERS = ("ttyUSB", "ttyACM", "cuaU")

I also added a FreeBSD-specific error message for the dialout group if the user is not in it:
elif sys.platform.startswith("freebsd"):
msg = (
"Could not access any serial ports. On FreeBSD, ensure "
"your user is in the 'dialer' group."
)

I still have problems getting a response from my machine but it might be a more FreeBSD-driver problem or machine problem. I do get it to home and to run the perimeter but nothing else and I get response on the device when sending GRBL commands... I will have to find a way to test it on Linux to test if it is FreeBSD specific or my machine. I will get back with this.

[knipknap]

Can you check if it would work with this Raygeo PR?

barebaric/raygeo#26