On Tue, Sep 24, 2019 at 11:09 PM John Stultz <john.stultz@xxxxxxxxxx> wrote: > > On Tue, Sep 24, 2019 at 4:30 PM John Stultz <john.stultz@xxxxxxxxxx> wrote: > > On Tue, Sep 24, 2019 at 3:24 PM Rob Herring <robh@xxxxxxxxxx> wrote: > > > Trying to maintain something that works across more than 3 releases or > > > so is painful. I don't think android-x86 folks have the bandwidth to > > > maintain things older than that *and* update to newer versions. So I > > > think only supporting the n latest releases is good. > > > > > > Are .bp files for master/Q compatible back to N (or O)? IIRC, at least > > > for the first couple of releases with .bp files, they seemed to have > > > incompatible changes. > > > > I think there have possibly been some incompatible changes, as I know > > early w/ bp files things were more in flux. That said, there haven't > > been many changes to the libdrm bp files since the conversion was > > first done in 2017 (so Android O). I'll checkout N and validate so I > > can provide a more concrete assurance. > > Ah. Crud. You're right. The bp syntax has shifted enough over time to > cause problems w/ the current file when building against older Android > releases. N falls over pretty hard, and O and even P have issues w/ > "recovery_available: ", and "prebuilt_etc" syntax. So my proposed > commit message mischaracterizes the state of older builds. Apologies! The CrOS/arc++ approach to build mesa using meson as an android vendor blob, more decoupled from android build system, seems nicer every day ;-) Side note, unless you are also caring about new libdrm + old mesa, you can drop libdrm_freedreno from Android.mk/Android.bp.. we've pulled it in to $mesa/src/freedreno/drm, an old version only remains in libdrm for older mesa and for a couple dev/test tools that I use. BR, -R > I'll try to reach out to the android devs to see if there's any sort > of compat magic that can be done to keep things working on older > versions. That said, I'm still torn, as without this the current > libdrm/master code is broken with AOSP/master and Q. Its frustrating > we have to have this seemingly exclusive trade off. > > I'm curious if folks might be willing to consider something like an > upstream branch to preserve the build bits that work with prior > Android releases? Or any other ideas? > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
