[PATCH] libdrm: Convert to Android.mk to Android.bp
Rob Clark
robdclark at gmail.com
Wed Sep 25 16:04:20 UTC 2019
On Tue, Sep 24, 2019 at 11:09 PM John Stultz <john.stultz at linaro.org> wrote:
>
> On Tue, Sep 24, 2019 at 4:30 PM John Stultz <john.stultz at linaro.org> wrote:
> > On Tue, Sep 24, 2019 at 3:24 PM Rob Herring <robh at kernel.org> 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?
>
More information about the dri-devel
mailing list