4 ms·
> In Part I, I had to patch qtmultimedia for the camera to work, but Qt compilation is ressource hungry, same goes for the osrm compilation, the memory of the R
by dev_dull 8y ago
> In Part I, I had to patch qtmultimedia for the camera to work, but Qt compilation is ressource hungry, same goes for the osrm compilation, the memory of the Raspberry Pi is too small
I was just thinking about this today. Is it possible to set up an arm VM for “dev” and port the binaries over to the RPI?
- akhenakh 8y agoqemu is capable of emulating an ARM cpu so yes but won't be able to emulate all the real hardware, especially the opengl ES gpu. From a compilation perspective I believe using a cross compiler is way more efficient than emulating the whole system.
- microcolonel 8y ago> ...especially the OpenGL ES GPU... Does Virgil3D not work in DBT QEMU targets? Generally agree that cross-compilation is a better solution, but I think it could also be nice to have everything (except the drivers for your actual hardware) tested as delivered.
- vetrom 8y agoWith a not insane amount of work you can get a cross compile toolchain up and at least make binaries. Not a lot of packaging systems focus on the cross-compile workflow for package generation though. (I mean there are some, but it's not exactly the standard for fedora or debian.)
- inferiorhuman 8y agoCross compiling is doable and easier with the newer versions of Debian. One Qt issue I had is that a bunch of stuff is dependent upon OpenGL, which wasn't well supported with the Pi stuff when I was poking around at it. Qt is also just a beast to cross-compile. Rust is much, much nicer to cross compile but lacks a nice GUI. I've been poking at Cursive.rs for TUI stuff in an attempt to hack up my own scan tool so we'll see where that goes.