From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@kernel.org>,
Namhyung Kim <namhyung.kim@lge.com>,
LKML <linux-kernel@vger.kernel.org>, Jiri Olsa <jolsa@redhat.com>,
David Ahern <dsahern@gmail.com>
Subject: Re: [PATCH] perf tools: Use per-file CFLAGS in Makefile
Date: Tue, 24 Sep 2013 14:08:42 -0300 [thread overview]
Message-ID: <20130924170842.GA2634@ghostprotocols.net> (raw)
In-Reply-To: <87vc1qprny.fsf@sejong.aot.lge.com>
Em Tue, Sep 24, 2013 at 05:09:21PM +0900, Namhyung Kim escreveu:
> On Mon, 23 Sep 2013 11:26:59 +0200, Borislav Petkov wrote:
> > On Mon, Sep 23, 2013 at 06:15:09PM +0900, Namhyung Kim wrote:
> >> I replaced them to a single -w option since all we want to do is
> >> suppress any warning, right?
> > Do we? And besides, -w is a big hammer as it shuts up all warnings.
> > acme?
> > I think special handling those files grew out of necessity to shut up
> > some warnings but acme would know better.
Yes, there were reasons for disabling some warnings on some files, would
have to look at the git history to see...
commit 09c0211c0bb0e40231e6ee9a35041d467ed72f16
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri May 4 11:32:54 2012 -0700
perf: Turn off compiler warnings for flex and bison generated files
We don't know what types of warnings different versions of flex
and bison combined with different versions of gcc is going to
generate, so just punt and don't warn about anything.
This fixes the build of perf for me on an openSUSE 12.1 system.
commit 575bf1d04e908469d26da424b52fc1b12a1db9d8
Author: Kirill A. Shutemov <kirill@shutemov.name>
Date: Mon Jun 24 11:43:14 2013 +0300
perf tools: Fix build with perl 5.18
perl.h from new Perl release doesn't like -Wundef and -Wswitch-default:
etc.
> I don't know. I just thought there's not much thing we can do for those
> files other than shutting up all warnings.
> But if you think that's not the right thing, I'll keep the existing
> options. What do you think, Arnaldo?
I think keeping the existing options is the right thing to do, if some
of that can be simplified or made like you did it in your patch, then
that is the matter for a separate patch, with proper explanation.
- Arnaldo
next prev parent reply other threads:[~2013-09-24 17:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-16 2:11 [PATCH] perf tools: Use per-file CFLAGS in Makefile Namhyung Kim
2013-09-20 23:01 ` Borislav Petkov
2013-09-23 9:15 ` Namhyung Kim
2013-09-23 9:26 ` Borislav Petkov
2013-09-24 8:09 ` Namhyung Kim
2013-09-24 17:08 ` Arnaldo Carvalho de Melo [this message]
2013-09-27 0:38 ` Namhyung Kim
2013-09-21 12:47 ` Jiri Olsa
2013-09-23 9:17 ` Namhyung Kim
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=20130924170842.GA2634@ghostprotocols.net \
--to=acme@ghostprotocols.net \
--cc=a.p.zijlstra@chello.nl \
--cc=bp@alien8.de \
--cc=dsahern@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung.kim@lge.com \
--cc=namhyung@kernel.org \
--cc=paulus@samba.org \
/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;
as well as URLs for NNTP newsgroup(s).