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 B556CADCA for ; Thu, 12 Feb 2015 15:54:47 +0100 (CET) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1CEskFK013772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 12 Feb 2015 09:54:46 -0500 Received: from localhost.localdomain (vpn1-5-97.ams2.redhat.com [10.36.5.97]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1CEsje4011899; Thu, 12 Feb 2015 09:54:45 -0500 Message-ID: <54DCBEB4.30005@redhat.com> Date: Thu, 12 Feb 2015 16:54:44 +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: Stephen Hemminger References: <09445d1715453b2eff4399da998717b967b829b3.1423739602.git.pmatilai@redhat.com> <20150212063820.436b2221@uryu.home.lan> In-Reply-To: <20150212063820.436b2221@uryu.home.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 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: Thu, 12 Feb 2015 14:54:48 -0000 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. >> --- >> config/common_bsdapp | 1 + >> config/common_linuxapp | 1 + >> mk/toolchain/clang/rte.vars.mk | 5 ++++- >> mk/toolchain/gcc/rte.vars.mk | 5 ++++- >> mk/toolchain/icc/rte.vars.mk | 6 +++++- >> 5 files changed, 15 insertions(+), 3 deletions(-) >> >> diff --git a/config/common_bsdapp b/config/common_bsdapp >> index 57bacb8..a5687b3 100644 >> --- a/config/common_bsdapp >> +++ b/config/common_bsdapp >> @@ -362,6 +362,7 @@ CONFIG_RTE_KNI_VHOST_DEBUG_TX=n >> # Enable warning directives >> # >> CONFIG_RTE_INSECURE_FUNCTION_WARNING=n >> +CONFIG_RTE_ERROR_ON_WARNING=n >> >> # >> # Compile the test application >> diff --git a/config/common_linuxapp b/config/common_linuxapp >> index d428f84..0762f99 100644 >> --- a/config/common_linuxapp >> +++ b/config/common_linuxapp >> @@ -383,6 +383,7 @@ CONFIG_RTE_LIBRTE_XEN_DOM0=n >> # Enable warning directives >> # >> CONFIG_RTE_INSECURE_FUNCTION_WARNING=n >> +CONFIG_RTE_ERROR_ON_WARNING=n >> >> # >> # Compile the test application >> diff --git a/mk/toolchain/clang/rte.vars.mk b/mk/toolchain/clang/rte.vars.mk >> index 40cb389..12726e7 100644 >> --- a/mk/toolchain/clang/rte.vars.mk >> +++ b/mk/toolchain/clang/rte.vars.mk >> @@ -63,11 +63,14 @@ TOOLCHAIN_ASFLAGS = >> TOOLCHAIN_CFLAGS = >> TOOLCHAIN_LDFLAGS = >> >> -WERROR_FLAGS := -W -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes >> +WERROR_FLAGS := -W -Wall -Wstrict-prototypes -Wmissing-prototypes >> WERROR_FLAGS += -Wmissing-declarations -Wold-style-definition -Wpointer-arith >> WERROR_FLAGS += -Wnested-externs -Wcast-qual >> WERROR_FLAGS += -Wformat-nonliteral -Wformat-security >> WERROR_FLAGS += -Wundef -Wwrite-strings >> +ifeq ($(CONFIG_RTE_ERROR_ON_WARNING),y) >> +WERROR_FLAGS += -Werror >> +endif >> >> # process cpu flags >> include $(RTE_SDK)/mk/toolchain/$(RTE_TOOLCHAIN)/rte.toolchain-compat.mk >> diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk >> index 88f235c..bbd3c85 100644 >> --- a/mk/toolchain/gcc/rte.vars.mk >> +++ b/mk/toolchain/gcc/rte.vars.mk >> @@ -71,11 +71,14 @@ ifeq (,$(findstring -O0,$(EXTRA_CFLAGS))) >> endif >> endif >> >> -WERROR_FLAGS := -W -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes >> +WERROR_FLAGS := -W -Wall -Wstrict-prototypes -Wmissing-prototypes >> WERROR_FLAGS += -Wmissing-declarations -Wold-style-definition -Wpointer-arith >> WERROR_FLAGS += -Wcast-align -Wnested-externs -Wcast-qual >> WERROR_FLAGS += -Wformat-nonliteral -Wformat-security >> WERROR_FLAGS += -Wundef -Wwrite-strings >> +ifeq ($(CONFIG_RTE_ERROR_ON_WARNING),y) >> +WERROR_FLAGS += -Werror >> +endif >> >> # process cpu flags >> include $(RTE_SDK)/mk/toolchain/$(RTE_TOOLCHAIN)/rte.toolchain-compat.mk >> diff --git a/mk/toolchain/icc/rte.vars.mk b/mk/toolchain/icc/rte.vars.mk >> index e39d710..652cca8 100644 >> --- a/mk/toolchain/icc/rte.vars.mk >> +++ b/mk/toolchain/icc/rte.vars.mk >> @@ -69,8 +69,12 @@ TOOLCHAIN_ASFLAGS = >> # error #13368: loop was not vectorized with "vector always assert" >> # error #15527: loop was not vectorized: function call to fprintf cannot be vectorize >> # was declared "deprecated" >> -WERROR_FLAGS := -Wall -Werror-all -w2 -diag-disable 271 -diag-warning 1478 >> +WERROR_FLAGS := -Wall -w2 -diag-disable 271 -diag-warning 1478 >> WERROR_FLAGS += -diag-disable 13368 -diag-disable 15527 >> +ifeq ($(CONFIG_RTE_ERROR_ON_WARNING),y) >> +WERROR_FLAGS += -Werror-all >> +endif >> + >> >> # process cpu flags >> include $(RTE_SDK)/mk/toolchain/$(RTE_TOOLCHAIN)/rte.toolchain-compat.mk > > The -Werror is a real feature. Having dealt with legacy code where > there are lots of bugs which were already warnings being ignored, having > a big hard stop when errors are found is really good. > > The default should be on but I understand why you may want to turn it > off, but it should require some effort to do. I wholeheartedly agree with all that, when applied the developers of the codebase. I spent the last 7+ years of my life working on a piece of software that emitted well over six hundred "harmless" warnings on build when I started with it, trust me I have very little tolerance for introducing new compiler warnings. But placing that burden to users trying to compile a released version of the software does good to nobody. - Panu -