Linux kbuild/kconfig development
 help / color / mirror / Atom feed
From: Jonathan Toppins <jtoppins@cumulusnetworks.com>
To: Paul Bolle <pebolle@tiscali.nl>
Cc: Michal Marek <mmarek@suse.cz>, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH v1 kbuild for-next 1/2] makefiles: add config option to force all cc warnings to errors
Date: Tue, 17 Mar 2015 22:05:53 -0400	[thread overview]
Message-ID: <5508DD81.20006@cumulusnetworks.com> (raw)
In-Reply-To: <1426633120.15575.17.camel@x220>

On 3/17/15 6:58 PM, Paul Bolle wrote:
> On Tue, 2015-03-17 at 15:37 -0700, Jonathan Toppins wrote:
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> +config DEBUG_FORCE_CC_WARNINGS_TO_ERRORS
>> +	bool "Force cc warnings to errors"
>> +	default y
>
> No way.
>
>> +	help
>> +	  Simply enables the gcc compiler option -Werror for the entire
>> +	  build. If a compilation unit cannot handle -Werror by fixing the
>> +	  warning then that unit must suppress the cc warning using
>> +	  cc-disable-warning for that compilation unit in the unit's makefile.
>> +	  .
>
> (Why the dot?)
>
>> +	  This option is intended to be more in the developer's face and
>> +	  encourage effort of some kind to remove the compilation warning.
>> +	  .
>
> (Dot?)
>
>> +	  If unsure say y.
>
> Again, no way.
>
>> +
>>   endmenu # "Compiler options"
>>
>>   config MAGIC_SYSRQ
>
> Feel free to fix as many build warning as you can. I'd really appreciate
> that. But my x86_64 build of v4.0-rc4 is _almost_ warning free. And
> that's nice. And I find -Werror (and littering Makefiles with
> cc-disable-warning) just to remove the few warnings I still see plain
> silly. I'm sure the same holds for other people and their builds too.

Please note, I was not trying to imply using cc-disable-warning was a 
first resort option, sorry if it seemed like that. In fact in my opinion 
cc-disable-warning should almost never be used. Do you have a suggestion 
for better wording of this?

Some slight background on these patches, they were born out of the team 
here wanting to have a simple way of easily catching warnings during 
driver development. This seemed like the least cumbersome way. I 
understand if defaulting to yes is not advisable.

Will be happy to submit another patch defaulting to no and clean-up the 
Dots in the paragraphs. From the comments provided so far this approach 
would seem to address them, unless I am misunderstanding and in fact the 
general idea of compiling with -Werror is not wanted.

Appreciate the discussion.

-Jon

  parent reply	other threads:[~2015-03-18  2:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-17 22:37 [PATCH v1 kbuild for-next 1/2] makefiles: add config option to force all cc warnings to errors Jonathan Toppins
2015-03-17 22:37 ` [PATCH v1 kbuild for-next 2/2] modpost: add Kconfig option to report warnings as errors Jonathan Toppins
2015-03-17 22:58 ` [PATCH v1 kbuild for-next 1/2] makefiles: add config option to force all cc warnings to errors Paul Bolle
2015-03-17 23:15   ` Jonathan Toppins
2015-03-18 10:00     ` Paul Bolle
2015-03-18  2:05   ` Jonathan Toppins [this message]
2015-03-18 10:16     ` Paul Bolle
2015-03-18  8:32   ` Michal Marek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5508DD81.20006@cumulusnetworks.com \
    --to=jtoppins@cumulusnetworks.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=pebolle@tiscali.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox