What it says on the tin. Builds libffi as a static library for easy inclusion as a build.zig.zon
dependency, and provides fairly idiomatic Zig bindings so you don’t need to use @cImport()
.
I have a question that’s unrelated to the cImport/ffi subject but related to the way you packaged the library. It seems there are two ways of doing this. Either fork a library and add a build.zig (the way you did) and a less obtrusive way to create a zig project that depends on the original lib tarball and provide the zig build there.
What made you take the first route?
Honestly, no thought went into that decision. I just saw that Andrew had gone this route with some C libraries (FFmpeg etc) and copied the approach. I guess either approach is fine, really.
I suppose one small advantage is that, this way, you don’t pull in libffi’s test suite and (many) build system files, all of which are useless in this case. A disadvantage would be that it takes more effort to rebase on upstream (but that’s on me anyway, and I don’t mind).