You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my Rust program, I want to use a C library (ffmpeg) with an API that's not Rust-friendly in a couple ways:
The API is partially defined in terms of macros such as this one, and I'd rather not have to duplicate their definitions (and hope they never change):
#defineAVERROR_EOF FFERRTAG( 'E','O','F',' ')
The caller is expected to directly access struct fields rather than use accessor functions, and the struct layout changes from version to version (hopefully paired with the appropriate .so major version increments, or even C callers are screwed when the library gets upgraded) and/or based on ifdefs, so duplicating the struct layouts in Rust is brittle. Here's an example (minus comments and such):
(There's an existing Rust wrapper, but it took the duplication approach, and so there are problems if you compile against a different version than expected. I'd like to try another way.)
I want to make a tiny C library that simply provides a more Rust-friendly API surface: provides C functions to wrap the macros and access struct fields. So my Rust program will be using ffmpeg directly (for the parts that seem sensible/stable) and via my wrapper (for the rest).
but it looks like the cflags don't get passed to the gcc-built stuff; my #include <libavcodec/codec.h> doesn't work. Looking at pkg-config's source, I think I'd have to look at the pkg_config::Library, take the things that it carefully unpacked via parse_libs_cflags, and repack them into the cflags representation. That seems silly; I want a more direct way to pass them from pkg-config to gcc, as well as use them in my Rust program itself.
The text was updated successfully, but these errors were encountered:
let lib = pkg_config::Config::new().atleast_version("1.2").probe("some-dep").unwrap();letmut builder = gcc::Config::new();for i in&lib.include_paths{
builder.include(i);}
builder.include("src");
builder.file("foo/foo.c");
builder.compile("libfoo.a");
But I agree, it's less than stellar. It would be nice to have something like:
let lib = pkg_config::Config::new().atleast_version(...).probe(...).unwrap();
gcc::Config::new().include_paths(&lib.include_paths).file(...).compile(...);
In my Rust program, I want to use a C library (ffmpeg) with an API that's not Rust-friendly in a couple ways:
The API is partially defined in terms of macros such as this one, and I'd rather not have to duplicate their definitions (and hope they never change):
The caller is expected to directly access struct fields rather than use accessor functions, and the struct layout changes from version to version (hopefully paired with the appropriate .so major version increments, or even C callers are screwed when the library gets upgraded) and/or based on ifdefs, so duplicating the struct layouts in Rust is brittle. Here's an example (minus comments and such):
(There's an existing Rust wrapper, but it took the duplication approach, and so there are problems if you compile against a different version than expected. I'd like to try another way.)
I want to make a tiny C library that simply provides a more Rust-friendly API surface: provides C functions to wrap the macros and access struct fields. So my Rust program will be using ffmpeg directly (for the parts that seem sensible/stable) and via my wrapper (for the rest).
I tried doing this via this simple
build.rs
:but it looks like the cflags don't get passed to the gcc-built stuff; my
#include <libavcodec/codec.h>
doesn't work. Looking at pkg-config's source, I think I'd have to look at thepkg_config::Library
, take the things that it carefully unpacked viaparse_libs_cflags
, and repack them into the cflags representation. That seems silly; I want a more direct way to pass them from pkg-config to gcc, as well as use them in my Rust program itself.The text was updated successfully, but these errors were encountered: