[Mesa-dev] [RFC][PATCH 4/5] Android.mk: Add option to use vendor version of mesa

[Emil Velikov]

On 26 July 2018 at 18:38, John Stultz <john.stultz at linaro.org> wrote:
> On Thu, Jul 26, 2018 at 6:46 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 25 July 2018 at 20:52, John Stultz <john.stultz at linaro.org> wrote:
>>> On Wed, Jul 25, 2018 at 5:42 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>> On 25 July 2018 at 00:21, John Stultz <john.stultz at linaro.org> wrote:
>>>>> From: Yong Yao <yong.yao at 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