On 26 July 2018 at 18:38, John Stultz <john.stu...@linaro.org> wrote: > On Thu, Jul 26, 2018 at 6:46 AM, Emil Velikov <emil.l.veli...@gmail.com> > wrote: >> On 25 July 2018 at 20:52, John Stultz <john.stu...@linaro.org> wrote: >>> On Wed, Jul 25, 2018 at 5:42 AM, Emil Velikov <emil.l.veli...@gmail.com> >>> wrote: >>>> On 25 July 2018 at 00:21, John Stultz <john.stu...@linaro.org> wrote: >>>>> From: Yong Yao <yong....@intel.com> >>>>> >>>>> This is a forward port of a patch from the AOSP/master branch: >>>>> https://android.googlesource.com/platform/external/mesa3d/+/b1e5fad1db4c1d51c7ae3a033b100a8429ae5415%5E%21/ >>>>> >>>>> Which allows boards to provide their own custom copy of mesa. >>>>> >>>> Thanks for sorting these out John. >>>> >>>> My understanding was that when a custom project repo is used one >>>> handles that in the device manifest. Roughly as: >>>> - foo.xml -> contains vast majority of the git repos with associated >>>> tags/etc >>>> - local.xml -> removes any repo/project from ^^, adds new one >>>> >>>> Is that no longer the case, or I simply misremember how Android does >>>> things? >>> >>> So, I'm not aware of the specific history behind this patch. And I >>> can't speak for Google, there has been a general push via the Treble >>> efforts to standardize the Android system image, and to push vendors >>> to keep any device specific bits into their own device directory. So >>> there is a strong disincentive to modify projects in AOSP and in order >>> to include things like devboards into AOSP, the push has been to limit >>> any device specific changes to only the device directory git tree. >>> >>> So while one can technically still replace projects with local repos >>> (and this is very useful for development!), I think they do not want >>> folks doing this for shipping devices. >>> >> Hmm using the word "local" brought some assumptions that were never made. >> AFAICT the remove/add project manifest combo can be used local >> changes/testing as well as for "shipping devices". >> Can it not? >> >>> We are trying to make sure device support is pushed upstream to fdo, >>> and then align AOSP's mesa to that, but one could imagine a board that >>> doesn't have support upstream in mesa, and provides its own copy of >>> mesa in the device directory. This patch allows the build to override >>> the default mesa project with the vendor provided mesa. >>> >> Since the vendor will already need to add the project (git repo etc), >> what is the blocker from removing the existing one beforehand? >> Last I've tried - the repo tool gives you a nice and clear >> warning/error message. >> >> There is one case where this patch is a must. If repo forbids removing >> "core" Android projects via the manifest. > > I'm not saying the repo tool at all forbids removing/replacing entries > in the manifest. Its just a tool. > > I'm saying that if someone is replacing git trees that are part of the > system image in a shipping device, my understanding is they are likely > going to have more problems with treble compliance. There are probably > technical loopholes folks can get through and still do it, but I think > generally its becoming frowned upon. > > Its possible, but I doubt they would chose to enforce this policy via > the repo tool. > > Regardless, I'm not sure why such a trivial change to the Android.mk > that the Android developers found useful is cause for much objection, > but this one seems more trouble then its worth, so I'll drop it. > I'm fairly worried (this and 5/5) a couple of reasons: - there seems to be a better way to handle this - similar one liners have caused breakage in the past - see libdrm 4dfa458979c345ea5eb46749f545d78c09e3f244
I do agree with RobH - vendors should target upstream and resort to fork/custom Mesa only when absolutely needed. That said, I will repeat/rephrase an earlier comment of mine: Hacks could be merged, as long as they're properly documented and there's an outline for a long term solution. That's my personal take - others may disagree. HTH Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev