[PATCH] libdrm: Convert to Android.mk to Android.bp

[Mauro Rossi]

On Wed, Sep 25, 2019 at 6:17 PM John Stultz <john.stultz at linaro.org> wrote:

> On Wed, Sep 25, 2019 at 3:39 AM Eric Engestrom <eric.engestrom at intel.com>
> wrote:
> >
> > On Tuesday, 2019-09-24 23:09:08 -0700, John Stultz 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!
> > >
> > > 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?
> >
> > Is _not_ deleting Android.mk an option?
>
> Yea, the trouble is O and P will pick up the Android.bp files by
> default, so you'd still see the issues or you'd run into duplicate
> targets. I'm hoping I can still find some conditional magic tricks for
> Android.bp.  I need to look at Mauro's patches though.
>
> > That would have the obvious cost of duplicating the build system
> > maintenance effort, but if that's the only way to not drop support for
> > everything before Q...
>
> Yea, I'm not eager to have two android build systems in the tree.
> Having just one is duplicative enough.
>
> > (fwiw, my ack only applies with "reasonable" support of previous
> > versions :] )
>
> Of course, I'm not planning on submitting this change further until I
> can find something better.  Apologies again for my assumptions that it
> would work with older bp implementations.  My only defence is, in
> trying to validate w/ older releases yesterday, my build system pulled
> down 135G of data and now my repo is somehow unshallowed and taking 4
> times the amount of disk space it was using w/ just AOSP/master. :P So
> validating across AOSP versions is no trivial thing.
>
> thanks
> -john
>

For O & P builds if module names collision is avoided,
could Android.bp and Android.mk coexist in the same project?

Could it be possible to use Android.bp for all libdrm targets
but data/Android.bp,
removed and replaced by ./Android.mk with dummy module name and stripped
down to just install /system/vendor/etc/hwdata/amdgpu.ids target ?

If what I'm thinking may work, I could give it a try and report back

Mauro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190925/05f71bc6/attachment.html>