git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Carlo Arenas <carenas@gmail.com>,
	Emily Shaffer <emilyshaffer@google.com>,
	git@vger.kernel.org,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH v2] transport-helper: enforce atomic in push_refs_with_push
Date: Thu, 18 Jul 2019 17:22:34 +0200	[thread overview]
Message-ID: <20190718152234.GI20404@szeder.dev> (raw)
In-Reply-To: <xmqq8ssx53a0.fsf@gitster-ct.c.googlers.com>

On Tue, Jul 16, 2019 at 09:53:59AM -0700, Junio C Hamano wrote:
> Carlo Arenas <carenas@gmail.com> writes:

> >> +                       for (struct ref *it = remote_refs; it; it = it->next)
> >
> > moving "struct ref it" out of the loop, allows for building with ancient
> > compilers that don't support C90 (even if only by default) as I found
> > out while building pu in a Centos 6 box

> but I think we still reject variable definition in
> for loop control (we saw and rewrote another patch that tried to use
> it late last year).
> 
> Apparently, this one slipped our review process.

I expected that this will eventually happen after Travis CI's default
Linux image recently changed from Ubuntu 14.04 to 16.04; explanation
in the commit message below.

With that patch issues like this could be caught earlier, while they
are only in 'pu' but not yet in 'next'.  But do we really want to do
that, is that the right tradeoff?  Dunno...  Adding a dedicated CI job
just to check that there are no 'for' loop initial declarations seems
kind of excessive, even if it only builds but doesn't run the test
suite.  And I don't know whether there are any other undesired ("too
new") constructs that GCC 4.8 would catch but later compilers quietly
accept.

  --- >8 ---

Subject: [PATCH] travis-ci: build with GCC 4.8 as well

C99 'for' loop initial declaration, i.e. 'for (int i = 0; i < n; i++)',
is not allowed in Git's codebase yet, to maintain compatibility with
some older compilers.

Our Travis CI builds used to catch 'for' loop initial declarations,
because the GETTEXT_POISON job has always built Git with the default
'cc', which in Travis CI's previous default Linux image (based on
Ubuntu 14.04 Trusty) is GCC 4.8, and that GCC version errors out on
this construct (not only with DEVELOPER=1, but with our default CFLAGS
as well).  Alas, that's not the case anymore, becase after 14.04's EOL
Travis CI's current default Linux image is based on Ubuntu 16.04
Xenial [1] and its default 'cc' is now GCC 5.4, which, just like all
later GCC and Clang versions, simply accepts this construct, even if
we don't explicitly specify '-std=c99'.

Ideally we would adjust our CFLAGS used with DEVELOPER=1 to catch this
undesired construct already when contributors build Git on their own
machines.  Unfortunately, however, there seems to be no compiler
option that would catch only this particular construct without choking
on many other things, e.g. while a later compiler with '-std=c90'
and/or '-ansi' does catch this construct, it can't build Git because
of several screenfulls of other errors.

Add the 'linux-gcc-4.8' job to Travis CI, in order to build Git with
GCC 4.8, and thus to timely catch any 'for' loop initial declarations.
To catch those it's sufficient to only build Git with GCC 4.8, so
don't run the test suite in this job, because 'make test' takes rather
long [2], and it's already run five times in other jobs, so we
wouldn't get our time's worth.

[1] The Azure Pipelines builds have been using Ubuntu 16.04 images
    from the start, so I belive they never caught 'for' loop initial
    declarations.

[2] On Travis CI 'make test' alone would take about 9 minutes in this
    new job (without running httpd, Subversion, and P4 tests).  For
    comparison, starting the job and building Git with GCC 4.8 takes
    only about 2 minutes.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
 .travis.yml               |  4 ++++
 ci/run-build-and-tests.sh | 17 +++++++++++++----
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index ffb1bc46f2..fc5730b085 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -21,6 +21,10 @@ matrix:
       compiler:
       addons:
       before_install:
+    - env: jobname=linux-gcc-4.8
+      os: linux
+      dist: trusty
+      compiler:
     - env: jobname=Linux32
       os: linux
       compiler:
diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index cdd2913440..ff0ef7f08e 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -11,9 +11,9 @@ windows*) cmd //c mklink //j t\\.prove "$(cygpath -aw "$cache_dir/.prove")";;
 esac
 
 make
-make test
-if test "$jobname" = "linux-gcc"
-then
+case "$jobname" in
+linux-gcc)
+	make test
 	export GIT_TEST_SPLIT_INDEX=yes
 	export GIT_TEST_FULL_IN_PACK_ARRAY=true
 	export GIT_TEST_OE_SIZE=10
@@ -21,7 +21,16 @@ then
 	export GIT_TEST_COMMIT_GRAPH=1
 	export GIT_TEST_MULTI_PACK_INDEX=1
 	make test
-fi
+	;;
+linux-gcc-4.8)
+	# Don't run the tests; we only care about whether Git can be
+	# built with GCC 4.8, as it errors out on some undesired (C99)
+	# constructs that newer compilers seem to quietly accept.
+	;;
+*)
+	make test
+	;;
+esac
 
 check_unignored_build_artifacts
 
-- 
2.22.0.810.g50207c7d84



  parent reply	other threads:[~2019-07-18 15:22 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-02  0:53 [PATCH] transport-helper: enforce atomic in push_refs_with_push Emily Shaffer
2019-07-02 13:51 ` Johannes Schindelin
2019-07-02 18:27   ` Junio C Hamano
2019-07-03 18:56   ` Emily Shaffer
2019-07-03 19:01     ` Emily Shaffer
2019-07-03 19:41     ` Johannes Schindelin
2019-07-03 20:57       ` Emily Shaffer
2019-07-04  8:29         ` Johannes Schindelin
2019-07-09 20:23           ` Emily Shaffer
2019-07-02 19:06 ` Junio C Hamano
2019-07-02 20:16 ` Junio C Hamano
2019-07-03  0:09   ` Emily Shaffer
2019-07-02 21:37 ` Junio C Hamano
2019-07-03  0:08   ` Emily Shaffer
2019-07-03  9:10   ` SZEDER Gábor
2019-07-03 18:13     ` Junio C Hamano
2019-07-03 18:58       ` Emily Shaffer
2019-07-09 21:10 ` [PATCH v2] " Emily Shaffer
2019-07-10 17:44   ` Junio C Hamano
2019-07-10 17:53     ` Junio C Hamano
2019-07-11 21:14       ` Emily Shaffer
2019-07-11 20:57     ` Emily Shaffer
2019-07-11 21:13       ` Junio C Hamano
2019-07-11 21:19   ` [PATCH v3] " Emily Shaffer
2019-07-12 16:25     ` Junio C Hamano
2019-07-16  7:10   ` [PATCH v2] " Carlo Arenas
2019-07-16 16:53     ` Junio C Hamano
2019-07-16 17:21       ` [RFC/PATCH] CodingGuidelines: spell out post-C89 rules Junio C Hamano
2019-07-17  0:55         ` Jonathan Nieder
2019-07-17 16:03           ` Junio C Hamano
2019-07-19  1:15             ` Jonathan Nieder
2019-07-17  1:09         ` Bryan Turner
2019-07-17 16:05           ` Junio C Hamano
2019-07-16 18:00       ` [PATCH v2] transport-helper: enforce atomic in push_refs_with_push Carlo Arenas
2019-07-16 20:28       ` [PATCH] transport-helper: avoid var decl in for () loop control Junio C Hamano
2019-07-17  0:42         ` Jonathan Nieder
2019-07-18 15:22       ` SZEDER Gábor [this message]
2019-07-18 16:12         ` [PATCH v2] transport-helper: enforce atomic in push_refs_with_push Junio C Hamano
2019-07-18 23:46           ` SZEDER Gábor
2019-07-18 16:29         ` Eric Sunshine
2019-07-19  1:31         ` Jonathan Nieder
2019-07-19  4:49           ` Carlo Arenas
2019-07-19 19:15             ` Junio C Hamano
2019-07-27  8:43         ` SZEDER Gábor
2019-07-27 16:11           ` 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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20190718152234.GI20404@szeder.dev \
    --to=szeder.dev@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=carenas@gmail.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).