git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).