<div dir="ltr"><div>Hello</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 25, 2019 at 12:39 PM Eric Engestrom <<a href="mailto:eric.engestrom@intel.com">eric.engestrom@intel.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">On Tuesday, 2019-09-24 23:09:08 -0700, John Stultz wrote:<br>
> On Tue, Sep 24, 2019 at 4:30 PM John Stultz <<a href="mailto:john.stultz@linaro.org" target="_blank">john.stultz@linaro.org</a>> wrote:<br>
> > On Tue, Sep 24, 2019 at 3:24 PM Rob Herring <<a href="mailto:robh@kernel.org" target="_blank">robh@kernel.org</a>> wrote:<br>
> > > Trying to maintain something that works across more than 3 releases or<br>
> > > so is painful. I don't think android-x86 folks have the bandwidth to<br>
> > > maintain things older than that *and* update to newer versions. So I<br>
> > > think only supporting the n latest releases is good.<br></blockquote><div><br></div><div>N is not a problem, per se, but if there are non supported Blueprint module types used</div><div>it will not be possible to actually replicate Android.mk build rules to Android.bp and the build will be missing some targets (for example is not possible to install prebuilt files to $OUT)</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>
> > > Are .bp files for master/Q compatible back to N (or O)? IIRC, at least<br>
> > > for the first couple of releases with .bp files, they seemed to have<br>
> > > incompatible changes.<br>
> ><br>
> > I think there have possibly been some incompatible changes, as I know<br>
> > early w/ bp files things were more in flux. That said, there haven't<br>
> > been many changes to the libdrm bp files since the conversion was<br>
> > first done in 2017 (so Android O). I'll checkout N and validate so I<br>
> > can provide a more concrete assurance.<br>
> <br>
> Ah. Crud. You're right. The bp syntax has shifted enough over time to<br>
> cause problems w/ the current file when building against older Android<br>
> releases.   N falls over pretty hard, and O and even P have issues w/<br>
> "recovery_available: ", and "prebuilt_etc" syntax.  So my proposed<br>
> commit message mischaracterizes the state of older builds. Apologies!<br></blockquote><div><br></div><div>I confirm that when trying drm_hwcomposer master build with oreo-x86 (Android O based)<br></div><div>I had to do manual procedures relying on Android.mk preliminary build + Android.bp build [1] with some ugly workaround [2]</div><div><br></div><div>Procedure:</div><div><br></div><div>First build with Android.mk versions on drm_hwcomposer and libdrm<br>because /system/vendor/etc/hwdata/amdgpu.ids target required prebuild_etc module type<br>then I used used Android.bp branches of drm_hwcomposer and libdrm<br></div><div><br></div><div>[1] <a href="https://github.com/maurossi/drm/commits/blueprint_oreo-x86">https://github.com/maurossi/drm/commits/blueprint_oreo-x86</a> NOTE: inspired by <span style="background-color:rgb(234,245,255);color:rgb(68,77,86);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace;font-size:13px;white-space:pre-wrap">AOSP fa32e29 "Convert to Android.bp</span></div><div><br></div><div>[2] <a href="https://github.com/maurossi/drm/commit/8727ddbd29e592a54ac234be99f63f262d0ff529">https://github.com/maurossi/drm/commit/8727ddbd29e592a54ac234be99f63f262d0ff529</a></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'll try to reach out to the android devs to see if there's any sort<br>
> of compat magic that can be done to keep things working on older<br>
> versions. That said, I'm still torn, as without this the current<br>
> libdrm/master code is broken with AOSP/master and Q.  Its frustrating<br>
> we have to have this seemingly exclusive trade off.<br>
> <br>
> I'm curious if folks might be willing to consider something like an<br>
> upstream branch to preserve the build bits that work with prior<br>
> Android releases? Or any other ideas?<br>
<br>
Is _not_ deleting Android.mk an option?<br>
<br>
That would have the obvious cost of duplicating the build system<br>
maintenance effort, but if that's the only way to not drop support for<br>
everything before Q...<br>
<br>
(fwiw, my ack only applies with "reasonable" support of previous<br>
versions :] )<br></blockquote><div><br></div><div>Hi Eric,</div><div>in my case with both Android.mk and Android.bp the build is failing with duplicated module name error</div><div>Mauro</div></div></div>