<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 25, 2019 at 6:17 PM John Stultz <<a href="mailto:john.stultz@linaro.org">john.stultz@linaro.org</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 Wed, Sep 25, 2019 at 3:39 AM Eric Engestrom <<a href="mailto:eric.engestrom@intel.com" target="_blank">eric.engestrom@intel.com</a>> wrote:<br>
><br>
> 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>
> > > ><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>
> ><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>
Yea, the trouble is O and P will pick up the Android.bp files by<br>
default, so you'd still see the issues or you'd run into duplicate<br>
targets. I'm hoping I can still find some conditional magic tricks for<br>
Android.bp.  I need to look at Mauro's patches though.<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>
Yea, I'm not eager to have two android build systems in the tree.<br>
Having just one is duplicative enough.<br>
<br>
> (fwiw, my ack only applies with "reasonable" support of previous<br>
> versions :] )<br>
<br>
Of course, I'm not planning on submitting this change further until I<br>
can find something better.  Apologies again for my assumptions that it<br>
would work with older bp implementations.  My only defence is, in<br>
trying to validate w/ older releases yesterday, my build system pulled<br>
down 135G of data and now my repo is somehow unshallowed and taking 4<br>
times the amount of disk space it was using w/ just AOSP/master. :P So<br>
validating across AOSP versions is no trivial thing.<br>
<br>
thanks<br>
-john<br></blockquote><div><br></div><div>For O & P builds if module names collision is avoided, </div><div>could Android.bp and Android.mk coexist in the same project?<br></div><div><br></div><div>Could it be possible to use Android.bp for all libdrm targets but data/Android.bp, </div><div>removed and replaced by ./Android.mk with dummy module name and stripped down to just install /system/vendor/etc/hwdata/amdgpu.ids target ?</div><div><br></div><div>If what I'm thinking may work, I could give it a try and report back</div><div><br></div><div>Mauro<br></div></div></div>