On Fri, Jun 3, 2016 at 8:26 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 4 June 2016 at 01:33, Rob Herring <robherri...@gmail.com> wrote: >> On Fri, Jun 3, 2016 at 7:19 PM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> On 17 May 2016 at 23:29, Rob Herring <robherri...@gmail.com> wrote: >>>> On Tue, May 17, 2016 at 5:21 PM, Rob Clark <robdcl...@gmail.com> wrote: >>>>> On Tue, May 17, 2016 at 6:14 PM, Jose Fonseca <jfons...@vmware.com> wrote: >>>>>> On 17/05/16 22:43, Rob Clark wrote: >>>>>>> >>>>>>> On Tue, May 17, 2016 at 5:13 PM, Rob Herring <robherri...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
