From: Borislav Petkov <bp@amd64.org>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Ingo Molnar <mingo@kernel.org>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Michal Marek <mmarek@suse.cz>,
LKML <linux-kernel@vger.kernel.org>,
Borislav Petkov <borislav.petkov@amd.com>
Subject: Re: [PATCH v4 1/4] tools: Add Makefile.include
Date: Tue, 10 Apr 2012 22:58:49 +0200 [thread overview]
Message-ID: <20120410205849.GB30366@aftab> (raw)
In-Reply-To: <20120410202721.GA28293@merkur.ravnborg.org>
On Tue, Apr 10, 2012 at 10:27:21PM +0200, Sam Ravnborg wrote:
> Hi Borislav.
>
> Some random comments as I really did not look at this
> part of the patch-set before.
.. and I appreciate those, thanks.
> > +#
> > +# Include saner warnings here, which can catch bugs:
> > +#
> > +EXTRA_WARNINGS := -Wformat
> > +EXTRA_WARNINGS := $(EXTRA_WARNINGS) -Wformat-security
>
> Two general comments - and I know this is just something you copied...
Yep, I did from perf's Makefile.
> Why not use the += operator. The below looks like shell script syntax.
> And we use the += operator in other places - at least in the kernel stuff.
Yep, this makes this assignment monster a bit more readable, sure.
> AND WHY ALL THESE SCREAMING CAPITAL LETTERS?
> I know Makefiles and scripts are full of them - but that does not help
> the readability.
>
> For kbuild I generally shifted to use:
> - lower-case names for local stuff
> - Upper case letters for global stuff - properly prefixed to avoid collisions
> EXTRA_WARNINGS likely fall into the category global-stuff,
> but then a local variable could still be usefull.
Well, my intention was to have EXTRA_WARNINGS be a global variable which
all tools under tools/ could start using so that we can benefit from the
compiler doing some more extensive checking. Thus all caps, no?
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
next prev parent reply other threads:[~2012-04-10 20:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-10 15:20 [PATCH v4 0/4] tools: Add a toplevel Makefile Borislav Petkov
2012-04-10 15:20 ` [PATCH v4 1/4] tools: Add Makefile.include Borislav Petkov
2012-04-10 20:27 ` Sam Ravnborg
2012-04-10 20:58 ` Borislav Petkov [this message]
2012-04-10 15:20 ` [PATCH v4 2/4] tools: Add a toplevel Makefile Borislav Petkov
2012-04-10 20:33 ` Sam Ravnborg
2012-04-10 21:03 ` Borislav Petkov
2012-04-10 15:20 ` [PATCH v4 3/4] tools: Add a help target Borislav Petkov
2012-04-10 20:34 ` Sam Ravnborg
2012-04-10 15:20 ` [PATCH v4 4/4] tools: Connect to the kernel build system Borislav Petkov
2012-04-10 20:37 ` Sam Ravnborg
2012-04-10 21:04 ` Borislav Petkov
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=20120410205849.GB30366@aftab \
--to=bp@amd64.org \
--cc=acme@infradead.org \
--cc=borislav.petkov@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mmarek@suse.cz \
--cc=sam@ravnborg.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.