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

[Mauro Rossi <issor.oruam@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3398 bytes --]

Hello

On Wed, Sep 25, 2019 at 12:39 PM Eric Engestrom <eric.engestrom@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@linaro.org>
> wrote:
> > > On Tue, Sep 24, 2019 at 3:24 PM Rob Herring <robh@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.
>

N is not a problem, per se, but if there are non supported Blueprint module
types used
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)


> > > >
> > > > 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 confirm that when trying drm_hwcomposer master build with oreo-x86
(Android O based)
I had to do manual procedures relying on Android.mk preliminary build +
Android.bp build [1] with some ugly workaround [2]

Procedure:

First build with Android.mk versions on drm_hwcomposer and libdrm
because /system/vendor/etc/hwdata/amdgpu.ids target required prebuild_etc
module type
then I used used Android.bp branches of drm_hwcomposer and libdrm

[1] https://github.com/maurossi/drm/commits/blueprint_oreo-x86 NOTE:
inspired by AOSP fa32e29 "Convert to Android.bp

[2]
https://github.com/maurossi/drm/commit/8727ddbd29e592a54ac234be99f63f262d0ff529


> >
> > 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?
>
> 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...
>
> (fwiw, my ack only applies with "reasonable" support of previous
> versions :] )
>

Hi Eric,
in my case with both Android.mk and Android.bp the build is failing with
duplicated module name error
Mauro

[-- Attachment #1.2: Type: text/html, Size: 5051 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel