On Wed, Sep 25, 2019 at 6:17 PM John Stultz <[email protected]> wrote:
> On Wed, Sep 25, 2019 at 3:39 AM Eric Engestrom <[email protected]> > wrote: > > > > On Tuesday, 2019-09-24 23:09:08 -0700, John Stultz wrote: > > > On Tue, Sep 24, 2019 at 4:30 PM John Stultz <[email protected]> > wrote: > > > > On Tue, Sep 24, 2019 at 3:24 PM Rob Herring <[email protected]> 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
_______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
