Closed llyyr closed 1 year ago
By vendored crates do you mean a precompiled crate in crates.io?
I don't think this is feasible for C compatible libraries built with cargo-c
.
How do they handle packaging rav1e
?
Seems that it is done for rav1e-devel
, but it's simpler as it's a single crate.
I'm not sure how to easily fix this, creating a new repo for the dolby_vision
crate is annoying.
I've managed to workaround* it by doing echo "[workspace]" >> dolby_vision/Cargo.toml
instead (https://build.opensuse.org/package/view_file/home:llyyr/libdovi/libdovi.spec)
* https://github.com/rust-lang/cargo/issues/10872#issuecomment-1187326529
I'm not familiar enough with Rust's ecosystem to have useful suggestions, and it's entirely possible I'm doing something wrong here.
rav1e
don't have this problem because you're already building from the parent directory
Right, this is the solution that works to build libdovi
only.
It breaks doing anything in the parent directory as there would be multiple workspaces.
I'll have to see if removing the root workspace causes trouble, it would only make it more complicated to run all tests but this is fine.
https://github.com/quietvoid/dovi_tool/commit/346437f3c12017bcb5b2d8c24edeb0176ba8af02 should fix this.
I don't know if you need a Cargo.lock
file for the library, though. Usually they're not committed.
Probably going to have to make a new tag for this.
I've made the libdovi-3.1.2
tag.
Normally it should work, but feel free to reopen if it doesn't.
opensuse for example doesn't allow
cargo fetch
, so you must provide vendored crates but this doesn't work because cargo will always include any and all parentCargo.toml
even if explicit--manifest-path
is provided