opencv-rust VS cross

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?

I cross compile to Mac, bsd, windows, etc cross ... Works great for me with either docker or podman.

We are using https://github.com/cross-rs/cross.

There is some built-in support in rustc for cross-compiling, but getting the build to actually work can be tricky due to the need for an appropriate linker. Instead, we’re going to use the Cross crate, which used to be maintained by the Rust Embedded Working Group Tools group.

I have used cross before to cross compile from Linux to other Linux. It has a section on it's wiki about this. Maybe that could be of help.

You can use cross to build your application and copy the artifacts into an alpine armv7 container. It would also build faster due to using cross compilation rather than QEMU.

Looks like cross is the easiest way to get something cross-compiled but its Mac support is blocked behind building your own build image. Even that repo says that it might be broken.

Bonus: if you’re working with Rust and doing a lot of cross platform stuff, check out cross. It runs QEMU in docker so you can run tests on a bunch of different emulated targets easily- literally a one line setup, it’s kind of magical.

It's also not as naturally cross-compilable as Go, though that's partly a side-effect of not accepting being a semi-closed ecosystem to achieve that and cross exists as a stop-gap while things like cargo-zigbuild explore less drastic options.

Why not use cross? It manages all these dependencies in containers, no effort needed on your part.

Following cross docs, I found this in the Wiki about using a remote container engine. The article implies some knowledge which I lack so my question is: what is the use case for that? Would I be able to use toolchain defined in the docker image using those features? bash CROSS_REMOTE=1 cross build --target x86_64-unknown-linux-gnu