+1 since warnings might be potential errors. In my perspective, an excellent project is better to have 0 warnings.
Chris Olivier <cjolivie...@gmail.com>于2018年1月16日 周二上午2:27写道： > If enabled, it should only cause errors in Release builds, since having > warnings in WIP code is not unusual. > > In addition, different developers use different gcc/clang versions. Some > gcc versions, for instance, generate warnings where others do not. It > would not be fair to render unbuildable a developer who is using a newer > (or older) gcc version is different from CI. Can this argument be tied to > a particular compiler/platform/version? > > On Mon, Jan 15, 2018 at 9:43 AM, Marco de Abreu < > marco.g.ab...@googlemail.com> wrote: > > > +1 > > > > On Mon, Jan 15, 2018 at 6:27 PM, Pedro Larroy < > > pedro.larroy.li...@gmail.com> > > wrote: > > > > > Hi > > > > > > I would like to propose to compile in CI with warnings as errors for > > > increased code quality. This has a dual purpose: > > > > > > 1. Enforce a clean compilation output. Warnings often indicate > > > deficiencies in the code and hide new warnings which can be an > > > indicator of problems. > > > > > > 2. Warnings can surface bugs as has happened before. > > > > > > While this might be impractical in all architectures, I would propose > > > having the Linux and Clang build run without warnings in CI. > > > > > > I think we are very close to this as I personally have been fixing > > > warnings in Linux and OSX / Clang. > > > > > > References: > > > > > > https://github.com/apache/incubator-mxnet/pull/9398 > > > > > > http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/ > > > incubator-mxnet/detail/PR-9398/1/pipeline > > > > > > Pedro. > > > > > >
