From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 86D3EADEC for ; Mon, 23 Feb 2015 09:19:26 +0100 (CET) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1N8JPIm023816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 23 Feb 2015 03:19:25 -0500 Received: from localhost.localdomain (vpn1-4-48.ams2.redhat.com [10.36.4.48]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1N8JNHt022109; Mon, 23 Feb 2015 03:19:24 -0500 Message-ID: <54EAE28B.3070807@redhat.com> Date: Mon, 23 Feb 2015 10:19:23 +0200 From: Panu Matilainen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Neil Horman , Stephen Hemminger References: <09445d1715453b2eff4399da998717b967b829b3.1423739602.git.pmatilai@redhat.com> <20150212063820.436b2221@uryu.home.lan> <54DCBEB4.30005@redhat.com> <20150220175521.334a63c9@urahara> <20150221193339.GA17802@neilslaptop.think-freely.org> In-Reply-To: <20150221193339.GA17802@neilslaptop.think-freely.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] Make -Werror optional X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 08:19:27 -0000 On 02/21/2015 09:33 PM, Neil Horman wrote: > On Fri, Feb 20, 2015 at 05:55:21PM -0800, Stephen Hemminger wrote: >> On Thu, 12 Feb 2015 16:54:44 +0200 >> Panu Matilainen wrote: >> >>> On 02/12/2015 04:38 PM, Stephen Hemminger wrote: >>>> On Thu, 12 Feb 2015 13:13:22 +0200 >>>> Panu Matilainen wrote: >>>> >>>>> This adds new CONFIG_RTE_ERROR_ON_WARNING config option to enable >>>>> fail-on-warning compile behavior, defaulting to off. >>>>> >>>>> Failing build on warnings is a useful developer tool but its bad >>>>> for release tarballs which can and do get built with newer >>>>> compilers than what was used/available during development. Compilers >>>>> routinely add new warnings so code which built silently with cc X >>>>> might no longer do so with X+1. This doesn't make the existing code >>>>> any more buggier and failing the build in this case does not help >>>>> not help improve code quality of an already released version either. >> >> Hopefully distro's like RHEL will build with -Werror enabled >> and not allow build to go through with errors. >> > Thats usually what we do, yes. Um, nope. All Fedora and RHEL builds are done using a common base set of flags set centrally from rpm configuration, and that includes among other things -Wall but not -Werror, although since F21 -Werror=format-security is included since that there are relatively few false positives for that. The thing is, compiler warnings from compilers are just that: warnings, and often including hefty dose of false positives. A good package maintainer will look at the build logs of his/her packages, investigate warnings and send patches upstream to address them in oncoming versions where actually relevant, but generally a package maintainer in a distro is not responsible for achieving zero-warning build, nor should they. Take for example set-but-not-used warning introduced in gcc 4.6. Many of the warnings unearthed by that do indicate real potential issues in the software (a typical example being ignoring an allegedly unlikely error code from a syscall, sometimes dozens or even hundreds of them for larger projects) but its also typically code that's been in use for years and years without anybody noticing. That code does not suddenly become unusable just because its now being compiled by a compiler that detects this condition, and -Werror on distro level misplaces the burden of addressing years of upstream laziness on a packager who often has little to do with upstream. - Panu -