Seperate libdovi from dovi_tool for easier packaging
llyyr opened this issue · comments
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 parent Cargo.toml even if explicit --manifest-path is provided
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)
* rust-lang/cargo#10872 (comment)
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.
346437f 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.