support libcamera v0.7.0 and vendored builds - #83
Conversation
|
Thank you for the PR solving the cross compilation pains Could you take out the v0.7.0 additions? It is hard to review this PR with all the clutter, also #81 is now merged. I like the vendored feature because it should also solve #16 I think? But I'm not sure if having entire libcamera as a submodule is a good idea, since vendored option should be an edge case. I haven't looked how other projects do this, but I have seen some that clone dependency into out directory and compile it there. Another problem with vendored build is that there are a lot of opinionated libcamera build configuration options that may not work for everyone and I don't think we can/should expose everything to be configurable through features/env vars. I will need some time to think about this |
|
yes, better to clone libcamera on build step |
|
I agree that #17 needs sorting but im not sure this does that. This does not add any documentation. I have been bad at working on this lib and helping with things like cross compilation. But thats partly because there are a lot of different ways todo it and lots of people do it just fine. I use a SDK, lot of people use deb-bootstrap. given many people want to use this with a PI and the offical pi os then deb-bootstrap is a better way todo this than statically linking all of libcamera into a huge static bin. I use a custom OS, so i use the custom OS's sdk so I'm not as familiar with deb-bootstrap and hence have not put the effort into documenting it. But for most people deb-bootstrap is a better way to cross compile than creating a huge static bin like this will. |
This pr includes:
I use this for libcamera support in my Camera app:
https://github.com/cosmic-utils/camera
closes #82
helps #17 and #52