From: Jeff King <peff@peff.net>
To: larsxschneider@gmail.com
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement
Date: Mon, 8 Feb 2016 07:25:51 -0500 [thread overview]
Message-ID: <20160208122551.GD24217@sigill.intra.peff.net> (raw)
In-Reply-To: <1454921958-53129-1-git-send-email-larsxschneider@gmail.com>
On Mon, Feb 08, 2016 at 09:59:18AM +0100, larsxschneider@gmail.com wrote:
> From: Lars Schneider <larsxschneider@gmail.com>
>
> The global Travis-CI environment variable CFLAGS did not override the
> CFLAGS variable in the makefile. Pass CFLAGS as make variable to
> override it properly.
Makes sense.
> In addition to that, add '-Wdeclaration-after-statement' to make a
> Travis-CI build fail (because of '-Werror') if the code does not adhere
> to the Git coding style.
I think this is a good step, but is probably the tip of the iceberg. I
typically use:
-Wall -Werror -Wdeclaration-after-statement
-Wpointer-arith -Wstrict-prototypes -Wvla
-Wold-style-declaration -Wold-style-definition
Junio does his integration testing with a similar set, which I think you
can find in one of the scripts in his "todo" branch.
> I made this patch because Peff pointed out to me that "git style doesn't
> allow declaration-after-statement" [1]. I wonder if it would make sense
> to add this check even in the makefile [2]?
I think we keep the default CFLAGS to a pretty tame set, so that we
build out of the box on a large number of compilers. I know I have run
into problems with -Wold-style-* on clang (though perhaps that is no
longer the case, as I haven't tried recently), let alone truly antique
compilers.
I have, however, wondered if it would make sense to codify this
knowledge in the Makefile with an optional knob. E.g., let DEVELOPER=1
roughly mean "you are a git dev, you have a reasonably modern compiler,
and want to be as careful as possible before sending your patches".
> I am no make expert, but I
> also wonder why we don't use the override directive [3] for the CFLAGS?
> AFAIK this would allow a make invocation like this:
>
> make target CFLAGS+=-Wdeclaration-after-statement
I think it is rather the opposite. If we used:
override CFLAGS+= ...
in the Makefile, then if a user did:
make CFLAGS=...
we would add to their CFLAGS (whereas without the override, our
appending is ignored). Our Makefile solves that in a different way,
though. We pass $(ALL_CFLAGS) to the compiler, and that in turn is made
up of $(CFLAGS) and $(BASIC_CFLAGS). We assume the user tweaks the
former, and we set the latter based on Makefile knobs (e.g., NO_CURL,
etc).
-Peff
next prev parent reply other threads:[~2016-02-08 12:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-08 8:59 [PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement larsxschneider
2016-02-08 12:25 ` Jeff King [this message]
2016-02-09 10:06 ` Lars Schneider
2016-02-09 17:36 ` Jeff King
2016-02-09 17:47 ` Junio C Hamano
2016-02-09 20:51 ` Ramsay Jones
2016-02-09 18:42 ` Junio C Hamano
2016-02-09 18:46 ` Stefan Beller
2016-02-09 23:03 ` Roberto Tyley
2016-02-09 23:14 ` Junio C Hamano
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=20160208122551.GD24217@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=larsxschneider@gmail.com \
/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).