[Mesa-dev] CI job for Android builds

[Rob Herring]

On Fri, Jun 3, 2016 at 8:26 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 4 June 2016 at 01:33, Rob Herring <robherring2 at gmail.com> wrote:
>> On Fri, Jun 3, 2016 at 7:19 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 17 May 2016 at 23:29, Rob Herring <robherring2 at gmail.com> wrote:
>>>> On Tue, May 17, 2016 at 5:21 PM, Rob Clark <robdclark at gmail.com> wrote:
>>>>> On Tue, May 17, 2016 at 6:14 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>>>>>> On 17/05/16 22:43, Rob Clark wrote:
>>>>>>>
>>>>>>> On Tue, May 17, 2016 at 5:13 PM, Rob Herring <robherring2 at gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I'm in the process of setting up a CI job to track Android builds of
>>>>>>>> mesa master (ATM merging in a branch of commits needed to build which
>>>>>>>> are not yet upstream). It is mostly working now though I'm still
>>>>>>>> tweaking the setup a bit. It is built on AOSP master branch as well.
>>>>>>>>
>>>>>>>> Build errors/warnings are published here:
>>>>>>>>
>>>>>>>> https://ci.linaro.org/job/robher-aosp/lastBuild/parsed_console/
>>>>>>>>
>>>>>>>> I can add anyone who would like to get emails of errors.
>>>>>>>
>>>>>>>
>>>>>>> Great idea!
>>>>>>>
>>>>>>> I think appveyor (windows CI build) just spams all of mesa-dev for
>>>>>>> build breaks.. and I guess I don't see a reason not to do that for
>>>>>>> android CI builds as well.
>>>>>>>
>>>>>>
>>>>>> What do you mean by "spams"?  Do you mean to say the AppVeyor traffic is too
>>>>>> much?
>>>>>>
>>>>>
>>>>> only meant that it sends it to the whole list (and I'm not saying that
>>>>> is a bad thing).. don't read too much into my choice of words ;-)
>>>>>
>>>>>>
>>>>>> FYI, the notification settings are set such that AppVeyor does _not_ email
>>>>>> for _every_ failure.  It emails when the build goes from passing -> failed,
>>>>>> or failed -> passed.
>>>>>>
>>>>>> So, if the Windows build breaks while all Windows maitainers are on
>>>>>> vacation, there should be no spam.
>>>>>>
>>>>>> The only situation where there's spam is when there are intermetting build
>>>>>> failures.  We've seen a few of those (due to infrastructure issues), but
>>>>>> thankfully not too often.
>>>>>>
>>>>>>
>>>>>> I recommend similar notification settings.  Too many emails: everybody
>>>>>> ignores, or will setup rules to hide those emails.  No emails: nobody
>>>>>> notices.
>>>>>>
>>>>>
>>>>> yeah, that is a good point.. not too familiar w/ Jenkins but if it has
>>>>> similar settings, that sounds like a good idea..
>>>>
>>>> It does. Right now I have it set to email on every build (3 times a
>>>> day), so I'm not quite ready to spam everyone. First, I'd like to get
>>>> to a passing state and give it some time to make sure it is stable
>>>> (i.e. little/no AOSP master related breakage).
>>>>
>>> With things now building properly I'd imagine that you can toggle the
>>> notifications to mesa-dev ?
>>
>> Yeah, I need to do a bit more setup and make sure it only emails when
>> starting to fail before that happens.
>>
> Great.
>
>>> Sure there'll be the odd false alarm, but things should be reasonably OK.
>>>
>>> That said, there's ~9k of warnings though. Three quick ones I've noticed:
>>> ~900 Winitializer-overrides - that one is intentional. Disable in Android.mk
>>> ~900 Wpointer-arith - ideally we'll resolve that one, but I don't see
>>> it happening any times soon. Disable as well.
>>> ~2k3 Wtypedef-redefinition - incomplete definition of HAVE_LIBDRM.
>>> Please move all the scattered 'if gpu_drivers != swrast -DHAVE_LIBDRM'
>>> to the top level Android.mk/Android.common.mk.

BTW, everything is built twice for 32 and 64 bit, so fixing these gets
us under 1K.

>> Some of the warnings I think are around Cxx or C++xx features, and gcc
>> and clang have different defaults. What levels should we be targeting?
>>
> C one is already set (see Android.common.mk) to C99.

But should it be C11 to fix Wtypedef-redefinition?

> The C++ one ...
> not sure. Both swr and clover require c++11 although neither of those
> are build on Android.
>
> For the rest, I'd imaging -std=c++0x is fine ?

Isn't that the same as c++11 for anything but old compilers?

Rob