On Wed, Sep 25, 2019 at 3:39 AM 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.
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