opencv-rust VS Cargo

opencv

There is an OpenCV bindings crate. This example might be what you're after https://github.com/twistedfall/opencv-rust/blob/master/examples/video_capture.rs

For example, this is the build script of the opencv bindings: https://github.com/twistedfall/opencv-rust/blob/master/build.rs

I’m trying to get around a known build issue—it would be great for it to be fixed upstream, but I don’t have any control over it except for setting OUT_DIR during its compilation.

I've been using https://github.com/twistedfall/opencv-rust a lot lately and it's really fantastic, they've done a great job matching up with how C++ works, so there are definitely good examples out there.

I never tried it, but the OpenCV bindings might work.

I thought it was going to be unsafe because of how Mat is implemented (more information here). ... I tested it and it should be fine memory-wise. My thought was that the code below was going to be allowed to compile.

I added opencv-rust as a dependency to a project. It makes my builds and even cargo check s really slow. It seems to invoke the build.rs script every time even when just type checking. Is this intentional? Is there any way to avoid this?

Instead, what I'm talking about is that there is a (generally large) cost to contributions that maintainers have to pay. Rarely is a contribution merge-ready on the first pass. Instead, a maintainer has to work with the person to get it ready. The amount this is needed varies according to the needs of a project. People generally underestimate the complexity of a project their are contributing to. Take cargo build --dependencies-only which people want for docker caching. Frequently people bump the thread, thinking its trivial, saying how to resolve it, and are annoyed that it isn't solved. Thankfully one person stepped back and looked at the bigger picture, realized what the maintainers were trying to say, and wrote up a great report on what the challenge is. Similar for XDG support. Each iteration for each PR is also represents a context switch for the maintainer. Keeping up on all of this across all of their projects, especially when its spare time, means they also need to come back up to speed on this each time.

Next, I'd like to extend my thanks to u/epage. epage maintains several famous crates like clap, cargo-edit, toml_edit, and more. epage is not afraid of engaging in heated debates with others. Such a characteristic helps move things forward, as seen with the support for lints table in Cargo.toml and MSRV support in dependency resolution.

But in the future, Cargo might want more directories for different purposes: - data (for installing other stuff like manpages, see https://github.com/rust-lang/cargo/issues/2729) - state (for storing CLI history or maintaining internal state between runs for some novel features)

just look at the versions

If nothing more it's useful for Rust projects that need a git library. eg: cargo, cargo-generate

I have choosen Rust, because it is a fast, low level language. It has comparable performance to C and C++, but unlike them it has a built-in and streamlined solution for package management and documentation generation. I was able to use them in 5 minutes as a first timer.

Also cargo set-version is part of cargo-edit which is incredibly convenient for setting the build version from CI since Cargo still doesn’t provide a means of overriding the version on the command line.

Do note that cargo vendor can’t handle duplicated dependencies 1. Not a very widespread issue, but there are some projects that (even intentionally) have duplicated dependencies, which prevents this command from working with them.

1.70 Upgrade to LLVM 16 1.69 Debuginfo for build dependencies is now off if not explicitly set. This is expected to improve the overall build time.