<div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div style="font-size:12.8px"><div style="color:rgb(136,136,136);font-size:12.8px"><div style="font-size:small"><span style="color:rgb(34,34,34)">> Out of curiosity, is that the PinePhone Pro, or something else?</span></div><div style="font-size:small"><br></div><div style="font-size:small"><div><span style="color:rgb(34,34,34)">PinePhone Pro</span></div><br style="color:rgb(34,34,34)"><span style="color:rgb(34,34,34)">> Also, which Android version are you targetting ?</span><br style="color:rgb(34,34,34)"></div><div style="font-size:small"><span style="color:rgb(34,34,34)"><br></span></div><div style="font-size:small"><span style="color:rgb(34,34,34)">SDK 30</span></div><div style="font-size:small"><br></div><div style="font-size:small"><span style="color:rgb(34,34,34)">> Could you please disable mail link tracking when posting to the list ?</span><br></div><div style="font-size:small"><span style="color:rgb(34,34,34)"><br></span></div><div style="font-size:small"><span style="color:rgb(34,34,34)">Yes! Oops. I'm sending this from a corp machine where the extension is not installed, so hopefully that fixes it.</span></div><div style="font-size:small"><span style="color:rgb(34,34,34)"><br></span></div><div style="font-size:small"><span style="color:rgb(34,34,34)"><br></span></div><div style="font-size:small"><br></div></div></div></div></div></div></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 13, 2022 at 4:09 AM Laurent Pinchart <<a href="mailto:laurent.pinchart@ideasonboard.com">laurent.pinchart@ideasonboard.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
On Wed, Oct 12, 2022 at 11:11:26AM +0100, Kieran Bingham via libcamera-devel wrote:<br>
> Quoting Nicholas Roth via libcamera-devel (2022-10-12 04:16:03)<br>
> > Hello all,<br>
> > <br>
> > TL;DR: I would propose adding a top-level Android.bp Bazel-based build and<br>
> > tests to support building libcamera inline with AOSP to expose the<br>
> > libcamera HAL.<br>
> <br>
> Thanks for taking this on.<br>
<br>
Likewise, thank you for your offer to help supporting the Android build<br>
system.<br>
<br>
As a first comment, Android.bp files are meant for the Soong build<br>
system, not Bazel. They are similar (and the Android.bp syntax is<br>
intentionally similar to Bazel), but not identical. See<br>
<a href="https://android.googlesource.com/platform/build/soong/+/master/README.md" rel="noreferrer" target="_blank">https://android.googlesource.com/platform/build/soong/+/master/README.md</a><br>
for information about Soong.<br>
<br>
Then, to make this even more fun, Android has decided in 2020 to migrate<br>
to Bazel (<a href="https://source.android.com/docs/setup/build/bazel/introduction" rel="noreferrer" target="_blank">https://source.android.com/docs/setup/build/bazel/introduction</a>).<br>
This is work in progress, I don't know when it will land, and it will<br>
then deprecate both make and Soong.<br>
<br>
> > *Short intro because I'm new* (feel free to skip):<br>
> > I'm Nicholas, a long-time amateur programmer with ~10 years of industry<br>
> > experience now, although it doesn't seem like it's been that long. I've<br>
> > published work in distributed scale-out systems and for the last ~6 years,<br>
> > I've worked in AI. More relevant to you all, I have free time and a phone<br>
> > with an RK3399 SoC that I'd like to get supported in Waydroid.<br>
<br>
Out of curiosity, is that the PinePhone Pro, or something else ?<br>
<br>
Also, which Android version are you targetting ?<br>
<br>
> Welcome to the team! :-)<br>
> <br>
> > *Background*:<br>
> > There's been back-and-forth discussion on Kieran's personal GitHub account<br>
> > (link: <a href="https://github.com/kbingham/libcamera/pull/26" rel="noreferrer" target="_blank">https://github.com/kbingham/libcamera/pull/26</a><br>
> > <<a href="https://mailtrack.io/trace/link/9c70a621d6594480c04ab3722218fff2dec55196?notrack=1&url=https%3A%2F%2Fgithub.com%2Fkbingham%2Flibcamera%2Fpull%2F26&userId=4192442&signature=13231078163330ff" rel="noreferrer" target="_blank">https://mailtrack.io/trace/link/9c70a621d6594480c04ab3722218fff2dec55196?notrack=1&url=https%3A%2F%2Fgithub.com%2Fkbingham%2Flibcamera%2Fpull%2F26&userId=4192442&signature=13231078163330ff</a>>)<br>
<br>
Could you please disable mail link tracking when posting to the list ?<br>
<br>
> > about how to potentially build libcamera inline with AOSP. If I understand<br>
> > correctly, the original contributor proposed some minor changes and also a<br>
> <br>
> The minor changes/fixes could certainly be considered already when<br>
> posted to the list.<br>
<br>
Yes, those could be posted, reviewed and merged already, before<br>
completing the work on the build system.<br></blockquote><div><br></div><div>Will do. My fork currently does not build on SDK 30 due to additional compiler errors. My top priority is to get a working build so I can test changes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > major change that would add ~349 lines of Makefiles, including a deprecated<br>
> > Android.mk. The original contributor ran out of bandwidth recently and<br>
> <br>
> The build system is probably the hard part, and indeed it sounds like<br>
> there are two options.<br>
> <br>
> 1) an Android.mk 'wrapper' around the meson infrastructure<br>
> 2) A parallel build system.<br>
> <br>
> <br>
> 1. may become deprecated, but we don't know when. And the one thing I've<br>
> learnt about open source is - if you don't know when somethings going to<br>
> happen, it seems best sometimes to assume it won't until it does.<br>
<br>
It is officially deprecated already, what we don't know is when support<br>
for it will be dropped. It may be possible to find out, I recall seeing<br>
a public migration schedule plan a while ago, but can't find it at the<br>
moment. Given that Android is migrating to Bazel, they may not move<br>
forward with dropping support of make before they switch away from Soong<br>
too. Or maybe then will. It's hard to predict, they're not known for<br>
taking anybody but themselves into consideration in their plans.<br>
<br>
> Because it can be *far away in the future*  (Just like our first<br>
> libcamera stable API release :D)<br>
<br>
As long as an Android.mk wrapper around meson would be low maintenance,<br>
I don't mind having support for the deprecated make-based build system<br>
for the time being. Of course, if there was a way to nicely support<br>
Soong-based builds without a high maintenance effort, that would be<br>
better, but a "one step at a time" approach is fine with me.<br></blockquote><div><br></div><div>From what I'm seeing so far, I'm assuming we'll start with a Makefile-based approach. That's what I'm using now. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> 2. Is painful to maintain... but sounds like the route you are<br>
> interested in...<br>
<br>
I don't think we want to maintain two build systems in parallel. A<br>
proper integrating with Soong or Bazel would require bridging the gap<br>
between those and meson, as we have no plan to move away from meson for<br>
the time being.<br>
<br>
For Soong, the little I understand is that the Android.bp files are<br>
fully declarative, and any logic needs to be written in Soong plugins,<br>
in the Go language. As libcamera generates source files at build time,<br>
this generation logic would need to be implemented there. A meson<br>
developer once (during a session about the Android build system at the<br>
Linux Plumbers Conference a few years ago) publicly offered to write a<br>
meson frontend in Go, for integration with Soong (a meson frontend means<br>
a reimplementation of meson in Go, which would parse the meson.build<br>
files and output the data format expected by Soong to let the Soong<br>
backend generate ninja files).  The offer was rejected by the Android<br>
build system maintainer along the lines of "you can do whatever you<br>
want, we won't care, so it will likely break very quickly as we move<br>
forward". That wasn't very motivating.<br>
<br>
> > decided not to pursue their changes further, and I volunteered to carry<br>
> > this forward.<br>
> > <br>
> > *My Prior Work*<br>
> > I have tried building libcamera with these proposed changes inline with<br>
> > AOSP using sdk 30 under "/external/libcamera" (full procedure link:<br>
> > <a href="https://docs.google.com/document/d/1Sly_VH3w6wFIdE72WXijQegoHZh8IxEnJ9m0hH7GodU/edit" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1Sly_VH3w6wFIdE72WXijQegoHZh8IxEnJ9m0hH7GodU/edit</a><br>
> > <<a href="https://mailtrack.io/trace/link/e6ac3150dcbfa009e3880aa030d8176036dc2199?notrack=1&url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Sly_VH3w6wFIdE72WXijQegoHZh8IxEnJ9m0hH7GodU%2Fedit&userId=4192442&signature=abdf0877da91078c" rel="noreferrer" target="_blank">https://mailtrack.io/trace/link/e6ac3150dcbfa009e3880aa030d8176036dc2199?notrack=1&url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Sly_VH3w6wFIdE72WXijQegoHZh8IxEnJ9m0hH7GodU%2Fedit&userId=4192442&signature=abdf0877da91078c</a>>)<br>
> > and it does not work as intended as far as I can tell. Specifically,<br>
> > /vendor/lib/hw/<a href="http://camera.libcamera.so" rel="noreferrer" target="_blank">camera.libcamera.so</a><br>
> > <<a href="https://mailtrack.io/trace/link/f38ddeb643e9e502355e6d6c7078c4f678867495?url=http%3A%2F%2Fcamera.libcamera.so%2F&userId=4192442&signature=f3a416f93f49123b" rel="noreferrer" target="_blank">https://mailtrack.io/trace/link/f38ddeb643e9e502355e6d6c7078c4f678867495?url=http%3A%2F%2Fcamera.libcamera.so%2F&userId=4192442&signature=f3a416f93f49123b</a>><br>
> > does<br>
> > not get bundled into the Android images. This may be user error on my part,<br>
> > however.<br>
> > <br>
> > *Options for AOSP Inline Build*<br>
> > The way I can see, we have at least these options for building libcamera<br>
> > inline with AOSP. Personally, parallel build systems (see below) seems like<br>
> > the best option to me. Please feel free to jump in if I'm wrong about any<br>
> > of this or if you have options to add:<br>
> > <br>
> >    - Transition libcamera to Soong and build intuitively<br>
> >    Tradeoffs: Simplest and most consistent option, but potentially very<br>
> >    disruptive<br>
<br>
As Soong is already deprecated by Android given their move to Bazel,<br>
that's a dead end. Even if it wasn't the case, I don't think it would be<br>
an option, as Soong is Android-specific.<br>
<br>
> >    - Invoke Meson from Soong with a genrule, akin to what <a href="http://meson_cross.mk" rel="noreferrer" target="_blank">meson_cross.mk</a><br>
> >    <<a href="https://mailtrack.io/trace/link/8b8bf21362b7febf0a481b5bf274ad86d982180e?url=http%3A%2F%2Fmeson_cross.mk%2F&userId=4192442&signature=c34c1a84f1c76a29" rel="noreferrer" target="_blank">https://mailtrack.io/trace/link/8b8bf21362b7febf0a481b5bf274ad86d982180e?url=http%3A%2F%2Fmeson_cross.mk%2F&userId=4192442&signature=c34c1a84f1c76a29</a>><br>
> >     does<br>
> >    Tradeoffs: complex-- I would be happy to do this but I'll need help<br>
> >    understanding how <a href="http://meson_cross.mk" rel="noreferrer" target="_blank">meson_cross.mk</a><br>
> >    <<a href="https://mailtrack.io/trace/link/35387558b6d890dee771bdbfb1f7bf8f6132b75f?url=http%3A%2F%2Fmeson_cross.mk%2F&userId=4192442&signature=dfc9af2da8b37fa2" rel="noreferrer" target="_blank">https://mailtrack.io/trace/link/35387558b6d890dee771bdbfb1f7bf8f6132b75f?url=http%3A%2F%2Fmeson_cross.mk%2F&userId=4192442&signature=dfc9af2da8b37fa2</a>><br>
> > works;<br>
> >    probably harder than writing <a href="http://meson_cross.mk" rel="noreferrer" target="_blank">meson_cross.mk</a><br>
> >    <<a href="https://mailtrack.io/trace/link/fecb2bde4cbf9c1d4e4afb58415434f6bf142167?url=http%3A%2F%2Fmeson_cross.mk%2F&userId=4192442&signature=3458951a34f69bc0" rel="noreferrer" target="_blank">https://mailtrack.io/trace/link/fecb2bde4cbf9c1d4e4afb58415434f6bf142167?url=http%3A%2F%2Fmeson_cross.mk%2F&userId=4192442&signature=3458951a34f69bc0</a>><br>
> > was;<br>
> >    possibly infeasible since Soong is quite opinionated<br>
<br>
As far as I can tell it's not really possible indeed. As I wrote above,<br>
you'd need a Soong plugin in Go that generates the internal data format<br>
that Soong requires. It may be possible to have that plugin call the<br>
meson parser written in Python, but writing a meson frontend in Go may<br>
be easier. meson doesn't guarantee the stability of the API between its<br>
Python frontend and Python backends as far as I know.<br>
<br>
> >    - *Parallel build systems*-- Create an Android.bp file that would live<br>
> >    at the top-level of the libcamer repo in addition to the existing Meson<br>
> >    files. We would use Soong for Android, and Meson for other use-cases.<br>
> >    Tradeoffs: Less complex and less error-prone than invoking Meson from<br>
> >    Soong, and less disruptive than moving to Soong exclusively, but would<br>
> >    incur an increased maintenance burden compared to doing nothing or using a<br>
> >    single build system.<br>
<br>
This is the option I like the least, as it increases the maintenance<br>
burden and is pretty much guaranteed to lead to breakages.<br>
<br>
> >    - Android.mk-- Use a legacy (link:<br>
> >    <a href="https://source.android.com/docs/setup/build" rel="noreferrer" target="_blank">https://source.android.com/docs/setup/build</a><br>
> >    <<a href="https://mailtrack.io/trace/link/a590ddf9d4e0fc2459ff68e2943bcb5feb034056?notrack=1&url=https%3A%2F%2Fsource.android.com%2Fdocs%2Fsetup%2Fbuild&userId=4192442&signature=124f558360d74d95" rel="noreferrer" target="_blank">https://mailtrack.io/trace/link/a590ddf9d4e0fc2459ff68e2943bcb5feb034056?notrack=1&url=https%3A%2F%2Fsource.android.com%2Fdocs%2Fsetup%2Fbuild&userId=4192442&signature=124f558360d74d95</a>>)<br>
> >    Android.mk file and figure out how to get the proposed Android.mk and<br>
> >    <a href="http://meson_cross.mk" rel="noreferrer" target="_blank">meson_cross.mk</a><br>
> >    <<a href="https://mailtrack.io/trace/link/b47795745b452c00239c6966c5fabd90e9ff7a07?url=http%3A%2F%2Fmeson_cross.mk%2F&userId=4192442&signature=1528cb5f2f1cd6c7" rel="noreferrer" target="_blank">https://mailtrack.io/trace/link/b47795745b452c00239c6966c5fabd90e9ff7a07?url=http%3A%2F%2Fmeson_cross.mk%2F&userId=4192442&signature=1528cb5f2f1cd6c7</a>><br>
> > files<br>
> >    working and tested.<br>
> >    Tradeoffs: New code would depend on a legacy tool and Makefiles can be<br>
> >    error-prone and hard to read (not great), but the maintenance burden<br>
> >    *might* be lower than creating a parallel Android.bp build file.<br>
> <br>
> Of the above options, the only one that I don't think we could easily<br>
> merge would be a parallel build system. That would be difficult to<br>
> maintain.<br>
<br>
Another option which isn't listed above is to compile libcamera<br>
separately using meson, with the Android SDK providing the<br>
cross-compiler. This would be a manual process though, not integrated in<br>
the AOSP build system. This is the option that mesa has selected as far<br>
as I know, they faced the same issue as us as they use meson. They still<br>
support the historical make-based Android build system<br>
(<a href="https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/android" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/android</a>), if that<br>
doesn't work for any reason, then users have to build mesa manually.<br>
<br>
We also asked, in the same Android build system session at LPC that I<br>
mentioned above, if Android could provide a hook in their build system<br>
to ease integration of externally-compiled binaries in Android images.<br>
The answer was negative.<br>
<br>
> A wrapper around our build system with either an Android.mk or a Soong<br>
> genrule (or both!?) would be more reasonable in my opinion ... as long<br>
> as :<br>
>  <br>
> > *Test Plan*<br>
> <br>
> We have a way to at least compile test it ;-)<br></blockquote><div><br></div><div>Working on that right now! Looks like this actually has a few compile errors. Will ask for help on this list when/if I get stuck, if that's alright.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> > I'm not exactly sure how the libcamera community approaches testing. That<br>
> > said, I would write a sanity check based on<br>
> > <a href="https://source.android.com/docs/core/tests/development/blueprints" rel="noreferrer" target="_blank">https://source.android.com/docs/core/tests/development/blueprints</a><br>
> > <<a href="https://mailtrack.io/trace/link/566af31c86d4ae27635d28c2f28a21e50ddd700b?notrack=1&url=https%3A%2F%2Fsource.android.com%2Fdocs%2Fcore%2Ftests%2Fdevelopment%2Fblueprints&userId=4192442&signature=76612081ac230acc" rel="noreferrer" target="_blank">https://mailtrack.io/trace/link/566af31c86d4ae27635d28c2f28a21e50ddd700b?notrack=1&url=https%3A%2F%2Fsource.android.com%2Fdocs%2Fcore%2Ftests%2Fdevelopment%2Fblueprints&userId=4192442&signature=76612081ac230acc</a>>.<br>
> > Ideally, we would agree to run this before submitting new code. This is<br>
> > probably the weakest part of my proposal, and I'd love any resources on<br>
> > libcamera's testing philosophy and thoughts on how to make this stronger.<br>
> <br>
> We already have infrastructure that builds libcamera across various GCC<br>
> and clang versions. It also runs CTS (Chrome Test Suite) on a Chromebook<br>
> (IPU3) which tests the Android HAL layer.<br>
> <br>
> I would extend this to support compiling with either the Android.mk or<br>
> genrule wrappers (again, or both) ... as long as I'm guided on what is<br>
> required. I have a build machine with plenty of space and resources for<br>
> such a task.<br>
> <br>
> > *Next Steps*<br>
> > If this looks good to the community (parallel build systems option), I'll<br>
> > figure out how to make Android.bp work. Most likely though, we have more to<br>
> > discuss. I'm ready to hear your thoughts!<br>
> <br>
> Parallel build is the one that worries me. libcamera is already complex<br>
> to build, with many separate and sometimes optional components.<br>
> <br>
> Will it be a single file that covers our entire build? as well as the<br>
> configuration options for different platforms, and specially built IPA<br>
> proxies, and module signing? That sounds ... like a lot of work, and a<br>
> lot of maintenance.<br>
> <br>
> But now we're on the libcamera list - lets await more feedback.<br>
<br>
On thing that could already be done without waiting for the outcome of<br>
this discussion is to post, review and merge the patches that fix build<br>
issues with Android (I'm thinking about removing usage of<br>
std::filesystem for instance).<br></blockquote><div><br></div><div>I would like to have a working inline build before I post these. Currently, "activeState.agc.exposure = 10ms / configuration.sensor.lineDuration;" in <a href="https://github.com/rothn/libcamera/blob/aosp-inline-build/src/ipa/ipu3/algorithms/agc.cpp">https://github.com/rothn/libcamera/blob/aosp-inline-build/src/ipa/ipu3/algorithms/agc.cpp</a> causes a compiler error with SDK30 because libcamera::utils::Duration and `long long` have no common type. Not sure if it's a compiler bug or what, but I'm looking into it. I'm setting up my build environment based on these instructions: <a href="https://docs.google.com/document/d/1Sly_VH3w6wFIdE72WXijQegoHZh8IxEnJ9m0hH7GodU/edit">https://docs.google.com/document/d/1Sly_VH3w6wFIdE72WXijQegoHZh8IxEnJ9m0hH7GodU/edit</a> if it interests anyone.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Regards,<br>
<br>
Laurent Pinchart<br></blockquote><div><br></div><div>Thanks, and looking forward to more feedback!</div><div><br></div><div>-Nicholas</div></div></div>