Add FreeBSD platform support

[elliejs]

Summary

• Add build-job-freebsd.yml CI workflow for FreeBSD 15.0 using vmactions/freebsd-vm, with all dependencies from FreeBSD pkg (no conda-forge packages exist for FreeBSD). Follows the same two-phase generate/compile structure as the other platforms.
• Add [FreeBSD] platform section to ocp.toml with system include paths and FreeBSD symbol manifest.
• Update dump_symbols.py for lief <0.14 compatibility (lief.EXE_FORMATS fallback), fix a crash when lief.parse() returns None, and detect FreeBSD as a distinct ELF platform.
• Add FreeBSD case to CMakeLists.txt platform detection and job entry to bindings.yml.

Notes

• The clang Python bindings are pip-installed because the FreeBSD port (py311-clang 11.0) is too old to drive libclang 22 from llvm-devel.
• Companion pywrap PR Fix binding generation bugs, add FreeBSD support, resolve CMake MPI issue pywrap#62 with FreeBSD platform detection, clang support, CMake MPI support, and symbol manifest.

Test plan

• FreeBSD CI generate and compile phases complete successfully (requires pywrap changes from Fix binding generation bugs, add FreeBSD support, resolve CMake MPI issue pywrap#62)
• import OCP test passes in CI
• Stubs generated and uploaded
• Verified locally: full pywrap generate + ninja compile on FreeBSD 15.0

🤖 Generated with Claude Code

[elliejs]

I have no idea why that OSX 3.11 job failed. Clang itself segfaulted, it didn't even emit an error, so I think it's unrelated to this change. In my own fork (which also has my own forked pywrap, so slightly different), this check passes. pywrap sister PR here: CadQuery/pywrap#62

action run with passing osx 3.11 here: https://github.com/elliejs/OCP/actions/runs/28189561694/job/83530983484

[elliejs]

yeah I only changed the commit message but it all passes now, yay

[adam-urbanczyk]

I would expect no changes needed in ocp.toml except for the [FreeBSD] section. What is the reason of the remaining changes.

[elliejs]

Did some more testing. Turns out they're unnecessary. I added them early in my debugging because I thought they were necessary for some forward declaration errors I was having, but I fixed it in pywrap by properly qualifying types.

I've reverted them

[elliejs]

Just checking in because I don't want this to go stale, let me know if there's anything I can validate or explain on my side

[adam-urbanczyk]

Why are pywrap changes needed? I'd expect the generated code to be essentially identical with Linux version.

[elliejs]

clang doesn't tolerate the same level of permissiveness in the generated code that gcc does. Linux uses gcc by default and FreeBSD ships with clang by default.

The pywrap PR also fixes some existing bugs like the lack of default argument plumbing.

[adam-urbanczyk]

Could you elaborate? What is strictly needed for FreeBSD and what is a bugfix? AFAIR default args are in the bindings currently. I see LLM involvement and some unexpected changes and this makes me rather suspicious to begin with.

[elliejs]

Ok I was typing up a response but that led down a pretty rough rabbit hole. 1) I was wrong when I ascribed the reason for the pywrap changes being gcc vs clang. It's actually clang 21 vs clang 22. the conda builds only have access to clang 21, and so they still build fine. I can pin my build to clang 21 too, but eventually clang 22 is going to start causing issues later in the year when clang 22 ends up in conda and the version isn't pinned. this is because clang starts emitting the short name instead of the fully qualified name in version 22 so the generated templates start dropping the ClassName:: out front. This was most of the pywrap changes. Number 2) I think I wrangled the system include nonsense a little better in my second pass as I was stripping back the pywrap changes to as little as required for clang 21.

I think what I'm going to do is close both PRs (here and pywrap) and instead we'll build towards a working solution over the course of two or three PRs in each branch. Things that we still need / want and will be broken out in each PR:

pywrap:

1. there's a bug where arg.name needs to be corrected to arg.arg_name in macros.j2. This hasn't affected the upstream builds because OCP uses a cache for generated sources, so it hasn't been hit despite the fact that this is a problem in master.
2. default is misspelled defualt, and this drops default arguments (I think. This is a nice-to-have not a real dealbreaker so I didn't look back into it)
3. translation_unit.py --> by using -I, the include order for FreeBSD gets all out of whack and clang complains about search paths being out of order:

error: <cstddef> tried including <stddef.h> but didn't find libc++'s <stddef.h> header.           This usually means that your header search paths are not configured properly.           The header search paths should contain the C++ Standard Library headers before           any C Standard Library, and you are probably using compiler flags that make that           not be the case.

OCP:

1. blissfully little needs to change here. Just a new build yaml, and the lief changes to deal with the fact that FreeBSD is still on lief <0.14, which means handling a breaking change for where the EXE_FORMAT members live.
2. enable language C and quietly try to find MPI since FreeBSD VTK builds against MPI and MPI is a C project.

again, i'm going to close the two big changes and submit smaller prs so we'll build back up to everything in more reviewable and intelligible ways.

Thanks for sticking with me here