{"thread":{"id":"49576","subject":"On overriding make variables from the environment...","startedAt":"2018-10-16T18:45:44Z","lastAt":"2019-01-18T08:41:17Z","messageCount":33,"participants":["SZEDER Gábor","Jonathan Nieder","Johannes Schindelin","Junio C Hamano","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"360656","messageId":"20181016184537.GN19800@szeder.dev","threadId":"49576","inReplyTo":null,"subject":"On overriding make variables from the environment...","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-10-16T18:45:37Z","receivedAt":"2018-10-16T18:45:44Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Our Makefile has lines like these:\n\n CFLAGS = -g -O2 -Wall\n CC = cc\n AR = ar\n SPATCH = spatch\n\nNote the use of '=', not '?='. This means that these variables can be\noverridden from the command line, i.e. 'make CC=gcc-X.Y' will build\nwith that particular GCC version, but not from the environment, i.e.\n'CC=gcc-X.Y make' will still build with 'cc'.\n\nThis can be confusing for developers who come from other projects\nwhere they used to run 'CC=whatever make'.\n\nAnd our build jobs on Travis CI are badly affected by this. We have\ndedicated build jobs to build Git with GCC and Clang both on Linux and\nOSX from the very beginning (522354d70f (Add Travis CI support,\n2015-11-27)). But guess how Travis CI specifies which compiler to\nuse! With 'export CC=gcc' and 'export CC=clang', respectively.\nConsequently, our Clang Linux build job has always used gcc, because\nthat's where 'cc' points at on Linux by default, while the GCC OSX\nbuild job has always used Clang. Oh, well. Furthermore, see\n37fa4b3c78 (travis-ci: run gcc-8 on linux-gcc jobs, 2018-05-19), where\nDuy added an 'export CC=gcc-8' in an attempt to use a more modern\ncompiler, but this had no effect either.\n\nI'm not sure what to do. I'm fine with updating our 'ci/' scripts to\nexplicitly respect CC in the environment (either by running 'make\nCC=$CC' or by writing $CC into 'config.mak'). Or I could update our\nMakefile to use '?=' for specific variables, but:\n\n - I'm afraid to break somebody's setup relying on the current\n behavior and CC having different values in the environment and in\n 'config.mak'.\n\n - Where to stop, IOW which variables should be set with '?='?\n CFLAGS, LDFLAGS, CC, AR, ..., SPATCH, SPATCH_FLAGS? Dunno. We\n already have 'STRIP ?= strip' and there are variables that are\n checked explicitly (e.g. 'DEVELOPER=y make' works).\n\n Note also that prior to b05701c5b4 (Make CFLAGS overridable from\n make command line., 2005-08-06) our Makefile used 'CC?=gcc' as\n well.\n\n"},{"id":"360674","messageId":"20181016215456.GB96853@aiede.svl.corp.google.com","threadId":"49576","inReplyTo":"20181016184537.GN19800@szeder.dev","subject":"Re: On overriding make variables from the environment...","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-10-16T21:54:56Z","receivedAt":"2018-10-16T21:55:02Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nSZEDER Gábor wrote:\n\n> Our Makefile has lines like these:\n>\n> CFLAGS = -g -O2 -Wall\n> CC = cc\n> AR = ar\n> SPATCH = spatch\n>\n> Note the use of '=', not '?='.\n[...]\n> I'm not sure what to do. I'm fine with updating our 'ci/' scripts to\n> explicitly respect CC in the environment (either by running 'make\n> CC=$CC' or by writing $CC into 'config.mak'). Or I could update our\n> Makefile to use '?=' for specific variables, but:\n\nThat's a good question. I don't have a strong opinion myself, so I\ntend to trust larger projects like Linux to have thought this through\nmore, and they use 'CC = cc' as well. So I'd lean toward the updating\n'ci/' scripts approach, to do something like\n\n\tmake ${CC:+\"CC=$CC\"} ...\n\n(or the equivalent multi-line construction).\n\nThat also has the bonus of being explicit.\n\nJust my two cents,\nJonathan\n"},{"id":"360678","messageId":"20181016223330.GP19800@szeder.dev","threadId":"49576","inReplyTo":"20181016215456.GB96853@aiede.svl.corp.google.com","subject":"Re: On overriding make variables from the environment...","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-10-16T22:33:30Z","receivedAt":"2018-10-16T22:33:37Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Oct 16, 2018 at 02:54:56PM -0700, Jonathan Nieder wrote:\n> SZEDER Gábor wrote:\n> > Our Makefile has lines like these:\n> >\n> > CFLAGS = -g -O2 -Wall\n> > CC = cc\n> > AR = ar\n> > SPATCH = spatch\n> >\n> > Note the use of '=', not '?='.\n> [...]\n> > I'm not sure what to do. I'm fine with updating our 'ci/' scripts to\n> > explicitly respect CC in the environment (either by running 'make\n> > CC=$CC' or by writing $CC into 'config.mak'). Or I could update our\n> > Makefile to use '?=' for specific variables, but:\n> \n> That's a good question. I don't have a strong opinion myself, so I\n> tend to trust larger projects like Linux to have thought this through\n> more, and they use 'CC = cc' as well.\n\nI don't think Linux is a good example to follow in this case, see e.g.\n6d62c983f7 (Makefile: Change the default compiler from \"gcc\" to \"cc\",\n2011-12-20) (in short: Git is supposed to be buildable with compilers\nother than GCC as well, while Linux not really, so they can hardcode\n'CC = gcc').\n\nAlso, the projects I have on hand usually have 'CC = gcc' hardcoded in\ntheir Makefiles, too, but those Makefiles were generated by their\n./configure script (which in turn by ./autogen.sh...), and those tend\nto write CC from the environment into the generated Makefiles.\n\n"},{"id":"360688","messageId":"20181016224001.GC96853@aiede.svl.corp.google.com","threadId":"49576","inReplyTo":"20181016223330.GP19800@szeder.dev","subject":"Re: On overriding make variables from the environment...","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-10-16T22:40:01Z","receivedAt":"2018-10-16T22:40:06Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"SZEDER Gábor wrote:\n> On Tue, Oct 16, 2018 at 02:54:56PM -0700, Jonathan Nieder wrote:\n>> SZEDER Gábor wrote:\n\n>>> Our Makefile has lines like these:\n>>>\n>>> CFLAGS = -g -O2 -Wall\n>>> CC = cc\n>>> AR = ar\n>>> SPATCH = spatch\n[...]\n>>> I'm not sure what to do. I'm fine with updating our 'ci/' scripts to\n>>> explicitly respect CC in the environment (either by running 'make\n>>> CC=$CC' or by writing $CC into 'config.mak'). Or I could update our\n>>> Makefile to use '?=' for specific variables, but:\n>>\n>> That's a good question. I don't have a strong opinion myself, so I\n>> tend to trust larger projects like Linux to have thought this through\n>> more, and they use 'CC = cc' as well.\n>\n> I don't think Linux is a good example to follow in this case, see e.g.\n> 6d62c983f7 (Makefile: Change the default compiler from \"gcc\" to \"cc\",\n> 2011-12-20) (in short: Git is supposed to be buildable with compilers\n> other than GCC as well, while Linux not really, so they can hardcode\n> 'CC = gcc').\n\nNowadays Linux builds with clang as well. People also have other\nreasons to override the CC setting (cross-compiling, etc) and to\noverride other settings like CFLAGS.\n\n> Also, the projects I have on hand usually have 'CC = gcc' hardcoded in\n> their Makefiles, too, but those Makefiles were generated by their\n> ./configure script (which in turn by ./autogen.sh...), and those tend\n> to write CC from the environment into the generated Makefiles.\n\nYes, I think that's what makes travis's setup normally work. It makes\nsense to me since ./configure is expected to have more implicit or\nautomatic behavior. For \"make\", I kind of like that it doesn't depend\non environment variables that I am not thinking about when debugging a\nreported build problem.\n\nWhen building Git without autoconf, the corresponding place for\nsettings is config.mak. Would it make sense for the ci scripts to\nwrite a config.mak file?\n\nThanks,\nJonathan\n"},{"id":"360753","messageId":"20181017142923.GR19800@szeder.dev","threadId":"49576","inReplyTo":"20181016224001.GC96853@aiede.svl.corp.google.com","subject":"Re: On overriding make variables from the environment...","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-10-17T14:29:23Z","receivedAt":"2018-10-17T14:29:30Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Oct 16, 2018 at 03:40:01PM -0700, Jonathan Nieder wrote:\n> SZEDER Gábor wrote:\n> > On Tue, Oct 16, 2018 at 02:54:56PM -0700, Jonathan Nieder wrote:\n> >> SZEDER Gábor wrote:\n> \n> >>> Our Makefile has lines like these:\n> >>>\n> >>> CFLAGS = -g -O2 -Wall\n> >>> CC = cc\n> >>> AR = ar\n> >>> SPATCH = spatch\n> [...]\n> >>> I'm not sure what to do. I'm fine with updating our 'ci/' scripts to\n> >>> explicitly respect CC in the environment (either by running 'make\n> >>> CC=$CC' or by writing $CC into 'config.mak'). Or I could update our\n> >>> Makefile to use '?=' for specific variables, but:\n> >>\n> >> That's a good question. I don't have a strong opinion myself, so I\n> >> tend to trust larger projects like Linux to have thought this through\n> >> more, and they use 'CC = cc' as well.\n> >\n> > I don't think Linux is a good example to follow in this case, see e.g.\n> > 6d62c983f7 (Makefile: Change the default compiler from \"gcc\" to \"cc\",\n> > 2011-12-20) (in short: Git is supposed to be buildable with compilers\n> > other than GCC as well, while Linux not really, so they can hardcode\n> > 'CC = gcc').\n> \n> Nowadays Linux builds with clang as well. People also have other\n> reasons to override the CC setting (cross-compiling, etc) and to\n> override other settings like CFLAGS.\n> \n> > Also, the projects I have on hand usually have 'CC = gcc' hardcoded in\n> > their Makefiles, too, but those Makefiles were generated by their\n> > ./configure script (which in turn by ./autogen.sh...), and those tend\n> > to write CC from the environment into the generated Makefiles.\n> \n> Yes, I think that's what makes travis's setup normally work. It makes\n> sense to me since ./configure is expected to have more implicit or\n> automatic behavior. For \"make\", I kind of like that it doesn't depend\n> on environment variables that I am not thinking about when debugging a\n> reported build problem.\n> \n> When building Git without autoconf, the corresponding place for\n> settings is config.mak. Would it make sense for the ci scripts to\n> write a config.mak file?\n\nA first I though it doesn't, but it turns out it acually does.\n\n'ci/run-build-and-tests.sh' basically runs:\n\n make\n make test\n\nI naively put a 'CC=$CC' argument at the end of the first command,\nthinking it should Just Work... but then that second 'make test' got\nall clever on me, said \"* new build flags\", and then proceeded to\nrebuild everything with the default 'cc'. (With the additional\ncomplication, that on Travis CI we actually run 'make --quiet test',\nwhich rebuilds everything, well, quietly... so the rebuild itself is\nnot even visible in the build logs.)\n\nSo, then it's either 'config.mak', or passing a 'CC=$CC' argument to\n_all_ make commands, including those that are not supposed to build\nanything, but only run the tests. I find the latter aesthetically not\nparticularly pleasing.\n\n"},{"id":"360838","messageId":"nycvar.QRO.7.76.6.1810181159200.4546@tvgsbejvaqbjf.bet","threadId":"49576","inReplyTo":"20181017142923.GR19800@szeder.dev","subject":"Re: On overriding make variables from the environment...","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-10-18T10:01:01Z","receivedAt":"2018-10-18T10:00:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Gábor,\n\nOn Wed, 17 Oct 2018, SZEDER Gábor wrote:\n\n> On Tue, Oct 16, 2018 at 03:40:01PM -0700, Jonathan Nieder wrote:\n> > SZEDER Gábor wrote:\n> > > On Tue, Oct 16, 2018 at 02:54:56PM -0700, Jonathan Nieder wrote:\n> > >> SZEDER Gábor wrote:\n> > \n> > >>> Our Makefile has lines like these:\n> > >>>\n> > >>> CFLAGS = -g -O2 -Wall\n> > >>> CC = cc\n> > >>> AR = ar\n> > >>> SPATCH = spatch\n> > [...]\n> > >>> I'm not sure what to do. I'm fine with updating our 'ci/' scripts to\n> > >>> explicitly respect CC in the environment (either by running 'make\n> > >>> CC=$CC' or by writing $CC into 'config.mak'). Or I could update our\n> > >>> Makefile to use '?=' for specific variables, but:\n> > >>\n> > >> That's a good question. I don't have a strong opinion myself, so I\n> > >> tend to trust larger projects like Linux to have thought this through\n> > >> more, and they use 'CC = cc' as well.\n> > >\n> > > I don't think Linux is a good example to follow in this case, see e.g.\n> > > 6d62c983f7 (Makefile: Change the default compiler from \"gcc\" to \"cc\",\n> > > 2011-12-20) (in short: Git is supposed to be buildable with compilers\n> > > other than GCC as well, while Linux not really, so they can hardcode\n> > > 'CC = gcc').\n> > \n> > Nowadays Linux builds with clang as well. People also have other\n> > reasons to override the CC setting (cross-compiling, etc) and to\n> > override other settings like CFLAGS.\n> > \n> > > Also, the projects I have on hand usually have 'CC = gcc' hardcoded in\n> > > their Makefiles, too, but those Makefiles were generated by their\n> > > ./configure script (which in turn by ./autogen.sh...), and those tend\n> > > to write CC from the environment into the generated Makefiles.\n> > \n> > Yes, I think that's what makes travis's setup normally work. It makes\n> > sense to me since ./configure is expected to have more implicit or\n> > automatic behavior. For \"make\", I kind of like that it doesn't depend\n> > on environment variables that I am not thinking about when debugging a\n> > reported build problem.\n> > \n> > When building Git without autoconf, the corresponding place for\n> > settings is config.mak. Would it make sense for the ci scripts to\n> > write a config.mak file?\n> \n> A first I though it doesn't, but it turns out it acually does.\n> \n> 'ci/run-build-and-tests.sh' basically runs:\n> \n> make\n> make test\n> \n> I naively put a 'CC=$CC' argument at the end of the first command,\n> thinking it should Just Work... but then that second 'make test' got\n> all clever on me, said \"* new build flags\", and then proceeded to\n> rebuild everything with the default 'cc'. (With the additional\n> complication, that on Travis CI we actually run 'make --quiet test',\n> which rebuilds everything, well, quietly... so the rebuild itself is\n> not even visible in the build logs.)\n> \n> So, then it's either 'config.mak', or passing a 'CC=$CC' argument to\n> _all_ make commands, including those that are not supposed to build\n> anything, but only run the tests. I find the latter aesthetically not\n> particularly pleasing.\n\nHow about using `MAKEFLAGS`? I ran a quick test:\n\n\tMAKEFLAGS='CC=blub' make -C .. git.o\n\tmake: Entering directory '/usr/src/git/wip'\n\t * new build flags\n\t CC git.o\n\t/bin/sh: blub: command not found\n\nIn other words, you could add something like this to the ci/ script:\n\n\tMAKEFLAGS=\"${MAKEFLAGS:+$MAKEFLAGS }CC=$CC\"\n\texport MAKEFLAGS\n\nCiao,\nDscho"},{"id":"360842","messageId":"xmqq1s8n5sjj.fsf@gitster-ct.c.googlers.com","threadId":"49576","inReplyTo":"20181017142923.GR19800@szeder.dev","subject":"Re: On overriding make variables from the environment...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-10-18T12:49:04Z","receivedAt":"2018-10-18T12:49:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor writes:\n\n> So, then it's either 'config.mak', or passing a 'CC=$CC' argument to\n> _all_ make commands, including those that are not supposed to build\n> anything, but only run the tests. I find the latter aesthetically not\n> particularly pleasing.\n\nThe config.mak file is available for individual builder-testers to\ncustomize their build, and in the context of this discussion, I\nthink the CI builder is just one particular individual who happens\nto be non human. If it is easy to throw suitable settings from within\nthe CI configuration .yaml files into config.mak, I'd think that is\nexactly how the mechanism was invented to be used, so...\n"},{"id":"365649","messageId":"20181220162452.17732-1-szeder.dev@gmail.com","threadId":"49576","inReplyTo":"20181016184537.GN19800@szeder.dev","subject":"[PATCH 0/5] travis-ci: build with the right compiler","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-12-20T16:24:47Z","receivedAt":"2018-12-20T16:25:15Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"\nOn Tue, Oct 16, 2018 at 08:45:37PM +0200, SZEDER Gábor wrote:\n> Our Makefile has lines like these:\n> \n> CFLAGS = -g -O2 -Wall\n> CC = cc\n> AR = ar\n> SPATCH = spatch\n> \n> Note the use of '=', not '?='. This means that these variables can be\n> overridden from the command line, i.e. 'make CC=gcc-X.Y' will build\n> with that particular GCC version, but not from the environment, i.e.\n> 'CC=gcc-X.Y make' will still build with 'cc'.\n> \n> This can be confusing for developers who come from other projects\n> where they used to run 'CC=whatever make'.\n> \n> And our build jobs on Travis CI are badly affected by this. We have\n> dedicated build jobs to build Git with GCC and Clang both on Linux and\n> OSX from the very beginning (522354d70f (Add Travis CI support,\n> 2015-11-27)). But guess how Travis CI specifies which compiler to\n> use! With 'export CC=gcc' and 'export CC=clang', respectively.\n> Consequently, our Clang Linux build job has always used gcc, because\n> that's where 'cc' points at on Linux by default, while the GCC OSX\n> build job has always used Clang. Oh, well. Furthermore, see\n> 37fa4b3c78 (travis-ci: run gcc-8 on linux-gcc jobs, 2018-05-19), where\n> Duy added an 'export CC=gcc-8' in an attempt to use a more modern\n> compiler, but this had no effect either.\n> \n> I'm not sure what to do. I'm fine with updating our 'ci/' scripts to\n> explicitly respect CC in the environment (either by running 'make\n> CC=$CC' or by writing $CC into 'config.mak').\n\nSo, this patch series, in particular the last patch fixes this issue\nby setting MAKEFLAGS to contain the right CC from the environment.\n\nThe first four patches are necessary cleanups/fixes to make it work,\nthough, arguably, the third patch is neither strictly necessary nor\nthat closely related to this series, but it just happened to bite me\nwhile working on this series.\n\n\nSZEDER Gábor (5):\n compat/obstack: fix -Wcast-function-type warnings\n .gitignore: ignore external debug symbols from GCC on macOS\n travis-ci: don't be '--quiet' when running the tests\n travis-ci: switch to Xcode 10.1 macOS image\n travis-ci: build with the right compiler\n\n .gitignore | 1 +\n .travis.yml | 2 ++\n ci/install-dependencies.sh | 5 +++++\n ci/lib-travisci.sh | 15 ++++++++++++---\n ci/run-build-and-tests.sh | 4 ++--\n ci/run-linux32-build.sh | 2 +-\n compat/obstack.c | 17 +++++++++--------\n compat/obstack.h | 18 +++++++++++-------\n 8 files changed, 43 insertions(+), 21 deletions(-)\n\n-- \n2.20.1.151.gec613c4b75\n\n"},{"id":"365650","messageId":"20181220162452.17732-2-szeder.dev@gmail.com","threadId":"49576","inReplyTo":"20181220162452.17732-1-szeder.dev@gmail.com","subject":"[PATCH 1/5] compat/obstack: fix -Wcast-function-type warnings","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-12-20T16:24:48Z","receivedAt":"2018-12-20T16:25:21Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"When building Git with GCC 8.2.0 (at least from Homebrew on macOS,\nDEVELOPER flags enabled) one is greeted with a screenful of compiler\nerrors:\n\n compat/obstack.c: In function '_obstack_begin':\n compat/obstack.c:162:17: error: cast between incompatible function types from 'void * (*)(long int)' to 'struct _obstack_chunk * (*)(void *, long int)' [-Werror=cast-function-type]\n h->chunkfun = (struct _obstack_chunk * (*)(void *, long)) chunkfun;\n ^\n compat/obstack.c:163:16: error: cast between incompatible function types from 'void (*)(void *)' to 'void (*)(void *, struct _obstack_chunk *)' [-Werror=cast-function-type]\n h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun;\n ^\n compat/obstack.c:116:8: error: cast between incompatible function types from 'struct _obstack_chunk * (*)(void *, long int)' to 'struct _obstack_chunk * (*)(long int)' [-Werror=cast-function-type]\n : (*(struct _obstack_chunk *(*) (long)) (h)->chunkfun) ((size)))\n ^\n compat/obstack.c:168:22: note: in expansion of macro 'CALL_CHUNKFUN'\n chunk = h->chunk = CALL_CHUNKFUN (h, h -> chunk_size);\n ^~~~~~~~~~~~~\n \n\n'struct obstack' stores pointers to two functions to allocate and free\n\"chunks\", and depending on how obstack is used, these functions take\neither one parameter (like standard malloc() and free() do; this is\nhow we use it) or two parameters. Presumably to reduce memory\nfootprint, a single field is used to store the function pointer for\nboth signatures, and then it's casted to the appropriate signature\nwhen the function pointer is accessed. These casts between function\npointers with different number of parameters are what trigger those\ncompiler errors.\n\nModify 'struct obstack' to use unions to store function pointers with\ndifferent signatures, and then use the union member with the\nappropriate signature when accessing these function pointers. This\neliminates the need for those casts, and thus avoids this compiler\nerror.\n\nSigned-off-by: SZEDER Gábor \n---\n compat/obstack.c | 17 +++++++++--------\n compat/obstack.h | 18 +++++++++++-------\n 2 files changed, 20 insertions(+), 15 deletions(-)\n\ndiff --git a/compat/obstack.c b/compat/obstack.c\nindex 4d1d95beeb..dd9504c684 100644\n--- a/compat/obstack.c\n+++ b/compat/obstack.c\n@@ -112,15 +112,15 @@ compat_symbol (libc, _obstack_compat, _obstack, GLIBC_2_0);\n \n # define CALL_CHUNKFUN(h, size) \\\n (((h) -> use_extra_arg) \\\n- ? (*(h)->chunkfun) ((h)->extra_arg, (size)) \\\n- : (*(struct _obstack_chunk *(*) (long)) (h)->chunkfun) ((size)))\n+ ? (*(h)->chunkfun.fn_extra_arg) ((h)->extra_arg, (size)) \\\n+ : (*(h)->chunkfun.fn) ((size)))\n \n # define CALL_FREEFUN(h, old_chunk) \\\n do { \\\n if ((h) -> use_extra_arg) \\\n- (*(h)->freefun) ((h)->extra_arg, (old_chunk)); \\\n+ (*(h)->freefun.fn_extra_arg) ((h)->extra_arg, (old_chunk)); \\\n else \\\n- (*(void (*) (void *)) (h)->freefun) ((old_chunk)); \\\n+ (*(h)->freefun.fn) ((old_chunk)); \\\n } while (0)\n \n \f\n@@ -159,8 +159,8 @@ _obstack_begin (struct obstack *h,\n size = 4096 - extra;\n }\n \n- h->chunkfun = (struct _obstack_chunk * (*)(void *, long)) chunkfun;\n- h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun;\n+ h->chunkfun.fn = chunkfun;\n+ h->freefun.fn = freefun;\n h->chunk_size = size;\n h->alignment_mask = alignment - 1;\n h->use_extra_arg = 0;\n@@ -206,8 +206,9 @@ _obstack_begin_1 (struct obstack *h, int size, int alignment,\n size = 4096 - extra;\n }\n \n- h->chunkfun = (struct _obstack_chunk * (*)(void *,long)) chunkfun;\n- h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun;\n+ h->chunkfun.fn_extra_arg = (struct _obstack_chunk * (*)(void *,long)) chunkfun;\n+ h->freefun.fn_extra_arg = (void (*) (void *, struct _obstack_chunk *)) freefun;\n+\n h->chunk_size = size;\n h->alignment_mask = alignment - 1;\n h->extra_arg = arg;\ndiff --git a/compat/obstack.h b/compat/obstack.h\nindex 6bc24b7644..0f9b2232a9 100644\n--- a/compat/obstack.h\n+++ b/compat/obstack.h\n@@ -160,11 +160,15 @@ struct obstack\t\t/* control current object in current chunk */\n void *tempptr;\n } temp;\t\t\t/* Temporary for some macros. */\n int alignment_mask;\t\t/* Mask of alignment for each object. */\n- /* These prototypes vary based on `use_extra_arg', and we use\n- casts to the prototypeless function type in all assignments,\n- but having prototypes here quiets -Wstrict-prototypes. */\n- struct _obstack_chunk *(*chunkfun) (void *, long);\n- void (*freefun) (void *, struct _obstack_chunk *);\n+ /* These prototypes vary based on `use_extra_arg'. */\n+ union {\n+ struct _obstack_chunk *(*fn_extra_arg) (void *, long);\n+ void *(*fn) (long);\n+ } chunkfun;\n+ union {\n+ void (*fn_extra_arg) (void *, struct _obstack_chunk *);\n+ void (*fn) (void *);\n+ } freefun;\n void *extra_arg;\t\t/* first arg for chunk alloc/dealloc funcs */\n unsigned use_extra_arg:1;\t/* chunk alloc/dealloc funcs take extra arg */\n unsigned maybe_empty_object:1;/* There is a possibility that the current\n@@ -235,10 +239,10 @@ extern void (*obstack_alloc_failed_handler) (void);\n \t\t (void (*) (void *, void *)) (freefun), (arg))\n \n #define obstack_chunkfun(h, newchunkfun) \\\n- ((h) -> chunkfun = (struct _obstack_chunk *(*)(void *, long)) (newchunkfun))\n+ ((h)->chunkfun.fn_extra_arg = (struct _obstack_chunk *(*)(void *, long)) (newchunkfun))\n \n #define obstack_freefun(h, newfreefun) \\\n- ((h) -> freefun = (void (*)(void *, struct _obstack_chunk *)) (newfreefun))\n+ ((h)->freefun.fn_extra_arg = (void (*)(void *, struct _obstack_chunk *)) (newfreefun))\n \n #define obstack_1grow_fast(h,achar) (*((h)->next_free)++ = (achar))\n \n-- \n2.20.1.151.gec613c4b75\n\n"},{"id":"365651","messageId":"20181220162452.17732-3-szeder.dev@gmail.com","threadId":"49576","inReplyTo":"20181220162452.17732-1-szeder.dev@gmail.com","subject":"[PATCH 2/5] .gitignore: ignore external debug symbols from GCC on macOS","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-12-20T16:24:49Z","receivedAt":"2018-12-20T16:25:22Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"When Git is build with a \"real\" GCC on macOS [1], or at least with GCC\ninstalled via Homebrew, and CFLAGS includes the '-g' option (and our\ndefault CFLAGS does), then by default GCC writes the debug symbols\ninto external files under '.dSYM/' directories (e.g.\n'git-daemon.dSYM/', 'git.dSYM/', etc.).\n\nUpdate '.gitignore' to ignore these directories, so they don't clutter\nthe output of 'git status'. Furthermore, these build artifacts then\nwon't trigger build failures on Travis CI via b92cb86ea1 (travis-ci:\ncheck that all build artifacts are .gitignore-d, 2017-12-31) once one\nof the following patches updates our CI build scripts to use a real\nGCC in the 'osx-gcc' build job.\n\n[1] On macOS the default '/usr/bin/gcc' executable is not a real GCC,\n but merely a compatibility wrapper around Clang:\n\n $ gcc --version\n Configured with: --prefix=<...>\n Apple LLVM version 9.0.0 (clang-900.0.39.2)\n <...>\n\n So even though 'make CC=gcc' does indeed execute a command called\n 'gcc', in the end Git will be built with Clang all the same.\n\nSigned-off-by: SZEDER Gábor \n---\n .gitignore | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/.gitignore b/.gitignore\nindex 0d77ea5894..a9db568712 100644\n--- a/.gitignore\n+++ b/.gitignore\n@@ -229,3 +229,4 @@\n *.pdb\n /Debug/\n /Release/\n+*.dSYM\n-- \n2.20.1.151.gec613c4b75\n\n"},{"id":"365652","messageId":"20181220162452.17732-4-szeder.dev@gmail.com","threadId":"49576","inReplyTo":"20181220162452.17732-1-szeder.dev@gmail.com","subject":"[PATCH 3/5] travis-ci: don't be '--quiet' when running the tests","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-12-20T16:24:50Z","receivedAt":"2018-12-20T16:25:24Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"All Travis CI build jobs run the test suite with 'make --quiet test'.\n\nOn one hand, being quiet doesn't save us from much clutter in the\noutput:\n\n $ make test |wc -l\n 861\n $ make --quiet test |wc -l\n 848\n\nIt only spares 13 lines, mostly the output of entering the 't/'\ndirectory and the pre- and post-cleanup commands, which is negligible\ncompared to the ~700 lines printed while building Git and the ~850\nlines of 'prove' output.\n\nOn the other hand, it's asking for trouble. In our CI build scripts\nwe build Git and run the test suite in two separate 'make'\ninvocations. In a prelimiary version of one of the later patches in\nthis series, to explicitly specify which compiler to use, I changed\nthem to basically run:\n\n make CC=$CC\n make --quiet test\n\nnaively thinking that it should Just Work... but then that 'make\n--quiet test' got all clever on me, noticed the changed build flags,\nand then proceeded to rebuild everything with the default 'cc'. And\nbecause of that '--quiet' option, it did so, well, quietly, only\nsaying \"* new build flags\", and it was by mere luck that I happened to\nnotice that something is amiss.\n\nLet's just drop that '--quiet' option when running the test suite in\nall build scripts.\n\nSigned-off-by: SZEDER Gábor \n---\n ci/run-build-and-tests.sh | 4 ++--\n ci/run-linux32-build.sh | 2 +-\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex cda170d5c2..84431c097e 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -8,7 +8,7 @@\n ln -s \"$cache_dir/.prove\" t/.prove\n \n make --jobs=2\n-make --quiet test\n+make test\n if test \"$jobname\" = \"linux-gcc\"\n then\n \texport GIT_TEST_SPLIT_INDEX=yes\n@@ -17,7 +17,7 @@ then\n \texport GIT_TEST_OE_DELTA_SIZE=5\n \texport GIT_TEST_COMMIT_GRAPH=1\n \texport GIT_TEST_MULTI_PACK_INDEX=1\n-\tmake --quiet test\n+\tmake test\n fi\n \n check_unignored_build_artifacts\ndiff --git a/ci/run-linux32-build.sh b/ci/run-linux32-build.sh\nindex 2c60d2e70a..26c168a016 100755\n--- a/ci/run-linux32-build.sh\n+++ b/ci/run-linux32-build.sh\n@@ -56,5 +56,5 @@ linux32 --32bit i386 su -m -l $CI_USER -c '\n \tcd /usr/src/git\n \ttest -n \"$cache_dir\" && ln -s \"$cache_dir/.prove\" t/.prove\n \tmake --jobs=2\n-\tmake --quiet test\n+\tmake test\n '\n-- \n2.20.1.151.gec613c4b75\n\n"},{"id":"365653","messageId":"20181220162452.17732-6-szeder.dev@gmail.com","threadId":"49576","inReplyTo":"20181220162452.17732-1-szeder.dev@gmail.com","subject":"[PATCH 5/5] travis-ci: build with the right compiler","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-12-20T16:24:52Z","receivedAt":"2018-12-20T16:25:27Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Our 'Makefile' hardcodes the compiler to build Git as 'CC = cc'. This\ncan be overridden from the command line, i.e. 'make CC=gcc-X.Y' will\nbuild with that particular GCC version, but not from the environment,\ni.e. 'CC=gcc-X.Y make' will still build with whatever 'cc' happens to\nbe on the platform.\n\nOur build jobs on Travis CI are badly affected by this. In the build\nmatrix we have dedicated build jobs to build Git with GCC and Clang\nboth on Linux and macOS from the very beginning (522354d70f (Add\nTravis CI support, 2015-11-27)). Alas, this never really worked as\nsupposed to, because Travis CI specifies the compiler for those build\njobs as 'export CC=gcc' and 'export CC=clang' (which works fine for\nprojects built with './configure && make'). Consequently, our\n'linux-clang' build job has always used GCC, because that's where 'cc'\npoints at in Travis CI's Linux images, while the 'osx-gcc' build job\nhas always used Clang. Furthermore, 37fa4b3c78 (travis-ci: run gcc-8\non linux-gcc jobs, 2018-05-19) added an 'export CC=gcc-8' in an\nattempt to build with a more modern compiler, but to no avail.\n\nSet MAKEFLAGS with CC based on the $CC environment variable, so 'make'\nwill run the \"right\" compiler. The Xcode 10.1 macOS image on Travis\nCI already contains the gcc@8 package from Homebrew, but we have to\n'brew link' it first to be able to use it.\n\nSo with this patch our build jobs will build Git with the following\ncompiler versions:\n\n linux-clang: clang version 5.0.0 (tags/RELEASE_500/final)\n linux-gcc: gcc-8 (Ubuntu 8.1.0-5ubuntu1~14.04) 8.1.0\n\n osx-clang: Apple LLVM version 10.0.0 (clang-1000.11.45.5)\n osx-gcc: gcc-8 (Homebrew GCC 8.2.0) 8.2.0\n\n GETTEXT_POISON: gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4\n\nSigned-off-by: SZEDER Gábor \n---\n ci/install-dependencies.sh | 5 +++++\n ci/lib-travisci.sh | 15 ++++++++++++---\n 2 files changed, 17 insertions(+), 3 deletions(-)\n\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex 06c3546e1e..dc719876bb 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -40,6 +40,11 @@ osx-clang|osx-gcc)\n \tbrew install git-lfs gettext\n \tbrew link --force gettext\n \tbrew install caskroom/cask/perforce\n+\tcase \"$jobname\" in\n+\tosx-gcc)\n+\t\tbrew link gcc@8\n+\t\t;;\n+\tesac\n \t;;\n StaticAnalysis)\n \tsudo apt-get -q update\ndiff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh\nindex 69dff4d1ec..a479613a57 100755\n--- a/ci/lib-travisci.sh\n+++ b/ci/lib-travisci.sh\n@@ -99,12 +99,14 @@ export DEFAULT_TEST_TARGET=prove\n export GIT_PROVE_OPTS=\"--timer --jobs 3 --state=failed,slow,save\"\n export GIT_TEST_OPTS=\"--verbose-log -x --immediate\"\n export GIT_TEST_CLONE_2GB=YesPlease\n-if [ \"$jobname\" = linux-gcc ]; then\n-\texport CC=gcc-8\n-fi\n \n case \"$jobname\" in\n linux-clang|linux-gcc)\n+\tif [ \"$jobname\" = linux-gcc ]\n+\tthen\n+\t\texport CC=gcc-8\n+\tfi\n+\n \texport GIT_TEST_HTTPD=YesPlease\n \n \t# The Linux build installs the defined dependency versions below.\n@@ -118,6 +120,11 @@ linux-clang|linux-gcc)\n \texport PATH=\"$GIT_LFS_PATH:$P4_PATH:$PATH\"\n \t;;\n osx-clang|osx-gcc)\n+\tif [ \"$jobname\" = osx-gcc ]\n+\tthen\n+\t\texport CC=gcc-8\n+\tfi\n+\n \t# t9810 occasionally fails on Travis CI OS X\n \t# t9816 occasionally fails with \"TAP out of sequence errors\" on\n \t# Travis CI OS X\n@@ -127,3 +134,5 @@ GIT_TEST_GETTEXT_POISON)\n \texport GIT_TEST_GETTEXT_POISON=YesPlease\n \t;;\n esac\n+\n+export MAKEFLAGS=\"CC=${CC:-cc}\"\n-- \n2.20.1.151.gec613c4b75\n\n"},{"id":"365654","messageId":"20181220162452.17732-5-szeder.dev@gmail.com","threadId":"49576","inReplyTo":"20181220162452.17732-1-szeder.dev@gmail.com","subject":"[PATCH 4/5] travis-ci: switch to Xcode 10.1 macOS image","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-12-20T16:24:51Z","receivedAt":"2018-12-20T16:25:28Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"When building something with GCC installed from Homebrew in the\ndefault macOS (with Xcode 9.4) image on Travis CI, it errors out with\nsomething like this:\n\n /usr/local/Cellar/gcc/8.1.0/lib/gcc/8/gcc/x86_64-apple-darwin17.5.0/8.1.0/include-fixed/stdio.h:78:10: fatal error: _stdio.h: No such file or directory\n #include <_stdio.h>\n ^~~~~~~~~~\n\nThis seems to be a common problem affecting several projects, and the\ncommon solution is to use a Travis CI macOS image with more recent\nXcode version, e.g. 10 or 10.1.\n\nWhile we don't use such a GCC yet, in the very next patch we will, so\nswitch our OSX build jobs to use the Xcode 10.1 image. Compared to\nthe Xcode 10 image, this has the benefit that it comes with GCC (v8.2)\npreinstalled from Homebrew.\n\nSigned-off-by: SZEDER Gábor \n---\n .travis.yml | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/.travis.yml b/.travis.yml\nindex 03c8e4c613..36cbdea7f4 100644\n--- a/.travis.yml\n+++ b/.travis.yml\n@@ -8,6 +8,8 @@ os:\n - linux\n - osx\n \n+osx_image: xcode10.1\n+\n compiler:\n - clang\n - gcc\n-- \n2.20.1.151.gec613c4b75\n\n"},{"id":"365711","messageId":"87zhszeqsr.fsf@evledraar.gmail.com","threadId":"49576","inReplyTo":"20181220162452.17732-2-szeder.dev@gmail.com","subject":"Re: [PATCH 1/5] compat/obstack: fix -Wcast-function-type warnings","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-12-20T23:12:20Z","receivedAt":"2018-12-20T23:12:24Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Dec 20 2018, SZEDER Gábor wrote:\n\n> When building Git with GCC 8.2.0 (at least from Homebrew on macOS,\n> DEVELOPER flags enabled) one is greeted with a screenful of compiler\n> errors:\n>\n> compat/obstack.c: In function '_obstack_begin':\n> compat/obstack.c:162:17: error: cast between incompatible function types from 'void * (*)(long int)' to 'struct _obstack_chunk * (*)(void *, long int)' [-Werror=cast-function-type]\n> h->chunkfun = (struct _obstack_chunk * (*)(void *, long)) chunkfun;\n> ^\n> compat/obstack.c:163:16: error: cast between incompatible function types from 'void (*)(void *)' to 'void (*)(void *, struct _obstack_chunk *)' [-Werror=cast-function-type]\n> h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun;\n> ^\n> compat/obstack.c:116:8: error: cast between incompatible function types from 'struct _obstack_chunk * (*)(void *, long int)' to 'struct _obstack_chunk * (*)(long int)' [-Werror=cast-function-type]\n> : (*(struct _obstack_chunk *(*) (long)) (h)->chunkfun) ((size)))\n> ^\n> compat/obstack.c:168:22: note: in expansion of macro 'CALL_CHUNKFUN'\n> chunk = h->chunk = CALL_CHUNKFUN (h, h -> chunk_size);\n> ^~~~~~~~~~~~~\n> \n\nWe originally got this from now-discontinued eglibc, but I notice that\nglibc.git's malloc/obstack.[ch]'s diff also changes these lines. If you\nbackport those do does that fix this warning?\n\nI.e. is this another case where we're blindly fixing bugs but should\njust re-import upstream's code instead?\n"},{"id":"366092","messageId":"nycvar.QRO.7.76.6.1901031659100.45@tvgsbejvaqbjf.bet","threadId":"49576","inReplyTo":"20181220162452.17732-6-szeder.dev@gmail.com","subject":"Re: [PATCH 5/5] travis-ci: build with the right compiler","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-01-03T16:01:25Z","receivedAt":"2019-01-03T16:01:34Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Gábor,\n\nOn Thu, 20 Dec 2018, SZEDER Gábor wrote:\n\n> Our 'Makefile' hardcodes the compiler to build Git as 'CC = cc'. This\n\n... This CC variable ...\n\n> can be overridden from the command line, i.e. 'make CC=gcc-X.Y' will\n> build with that particular GCC version, but not from the environment,\n> i.e. 'CC=gcc-X.Y make' will still build with whatever 'cc' happens to\n> be on the platform.\n\nWithout this edit, it read to me as if the commit message claimed that\nCC cannot be overridden via the environment *at all*, even with MAKEFLAGS.\n\nThe rest of the entire patch series looks good to me, I did not dig as\ndeeply as Ævar about that obstack patch, but if there is *some* sort of\nupstream from where we can get a fix, I think we should try to go for that\n(rather than risking to diverge even further).\n\nThanks,\nDscho\n\n> \n> Our build jobs on Travis CI are badly affected by this. In the build\n> matrix we have dedicated build jobs to build Git with GCC and Clang\n> both on Linux and macOS from the very beginning (522354d70f (Add\n> Travis CI support, 2015-11-27)). Alas, this never really worked as\n> supposed to, because Travis CI specifies the compiler for those build\n> jobs as 'export CC=gcc' and 'export CC=clang' (which works fine for\n> projects built with './configure && make'). Consequently, our\n> 'linux-clang' build job has always used GCC, because that's where 'cc'\n> points at in Travis CI's Linux images, while the 'osx-gcc' build job\n> has always used Clang. Furthermore, 37fa4b3c78 (travis-ci: run gcc-8\n> on linux-gcc jobs, 2018-05-19) added an 'export CC=gcc-8' in an\n> attempt to build with a more modern compiler, but to no avail.\n> \n> Set MAKEFLAGS with CC based on the $CC environment variable, so 'make'\n> will run the \"right\" compiler. The Xcode 10.1 macOS image on Travis\n> CI already contains the gcc@8 package from Homebrew, but we have to\n> 'brew link' it first to be able to use it.\n> \n> So with this patch our build jobs will build Git with the following\n> compiler versions:\n> \n> linux-clang: clang version 5.0.0 (tags/RELEASE_500/final)\n> linux-gcc: gcc-8 (Ubuntu 8.1.0-5ubuntu1~14.04) 8.1.0\n> \n> osx-clang: Apple LLVM version 10.0.0 (clang-1000.11.45.5)\n> osx-gcc: gcc-8 (Homebrew GCC 8.2.0) 8.2.0\n> \n> GETTEXT_POISON: gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4\n> \n> Signed-off-by: SZEDER Gábor \n> ---\n> ci/install-dependencies.sh | 5 +++++\n> ci/lib-travisci.sh | 15 ++++++++++++---\n> 2 files changed, 17 insertions(+), 3 deletions(-)\n> \n> diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\n> index 06c3546e1e..dc719876bb 100755\n> --- a/ci/install-dependencies.sh\n> +++ b/ci/install-dependencies.sh\n> @@ -40,6 +40,11 @@ osx-clang|osx-gcc)\n> \tbrew install git-lfs gettext\n> \tbrew link --force gettext\n> \tbrew install caskroom/cask/perforce\n> +\tcase \"$jobname\" in\n> +\tosx-gcc)\n> +\t\tbrew link gcc@8\n> +\t\t;;\n> +\tesac\n> \t;;\n> StaticAnalysis)\n> \tsudo apt-get -q update\n> diff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh\n> index 69dff4d1ec..a479613a57 100755\n> --- a/ci/lib-travisci.sh\n> +++ b/ci/lib-travisci.sh\n> @@ -99,12 +99,14 @@ export DEFAULT_TEST_TARGET=prove\n> export GIT_PROVE_OPTS=\"--timer --jobs 3 --state=failed,slow,save\"\n> export GIT_TEST_OPTS=\"--verbose-log -x --immediate\"\n> export GIT_TEST_CLONE_2GB=YesPlease\n> -if [ \"$jobname\" = linux-gcc ]; then\n> -\texport CC=gcc-8\n> -fi\n> \n> case \"$jobname\" in\n> linux-clang|linux-gcc)\n> +\tif [ \"$jobname\" = linux-gcc ]\n> +\tthen\n> +\t\texport CC=gcc-8\n> +\tfi\n> +\n> \texport GIT_TEST_HTTPD=YesPlease\n> \n> \t# The Linux build installs the defined dependency versions below.\n> @@ -118,6 +120,11 @@ linux-clang|linux-gcc)\n> \texport PATH=\"$GIT_LFS_PATH:$P4_PATH:$PATH\"\n> \t;;\n> osx-clang|osx-gcc)\n> +\tif [ \"$jobname\" = osx-gcc ]\n> +\tthen\n> +\t\texport CC=gcc-8\n> +\tfi\n> +\n> \t# t9810 occasionally fails on Travis CI OS X\n> \t# t9816 occasionally fails with \"TAP out of sequence errors\" on\n> \t# Travis CI OS X\n> @@ -127,3 +134,5 @@ GIT_TEST_GETTEXT_POISON)\n> \texport GIT_TEST_GETTEXT_POISON=YesPlease\n> \t;;\n> esac\n> +\n> +export MAKEFLAGS=\"CC=${CC:-cc}\"\n> -- \n> 2.20.1.151.gec613c4b75\n> \n> "},{"id":"366534","messageId":"xmqqef9k1a4n.fsf@gitster-ct.c.googlers.com","threadId":"49576","inReplyTo":"87zhszeqsr.fsf@evledraar.gmail.com","subject":"Re: [PATCH 1/5] compat/obstack: fix -Wcast-function-type warnings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-01-10T21:22:00Z","receivedAt":"2019-01-10T21:22:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> On Thu, Dec 20 2018, SZEDER Gábor wrote:\n>\n>> When building Git with GCC 8.2.0 (at least from Homebrew on macOS,\n>> DEVELOPER flags enabled) one is greeted with a screenful of compiler\n>> errors:\n>>\n>> compat/obstack.c: In function '_obstack_begin':\n>> compat/obstack.c:162:17: error: cast between incompatible function types from 'void * (*)(long int)' to 'struct _obstack_chunk * (*)(void *, long int)' [-Werror=cast-function-type]\n>> h->chunkfun = (struct _obstack_chunk * (*)(void *, long)) chunkfun;\n>> ^\n>> compat/obstack.c:163:16: error: cast between incompatible function types from 'void (*)(void *)' to 'void (*)(void *, struct _obstack_chunk *)' [-Werror=cast-function-type]\n>> h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun;\n>> ^\n>> compat/obstack.c:116:8: error: cast between incompatible function types from 'struct _obstack_chunk * (*)(void *, long int)' to 'struct _obstack_chunk * (*)(long int)' [-Werror=cast-function-type]\n>> : (*(struct _obstack_chunk *(*) (long)) (h)->chunkfun) ((size)))\n>> ^\n>> compat/obstack.c:168:22: note: in expansion of macro 'CALL_CHUNKFUN'\n>> chunk = h->chunk = CALL_CHUNKFUN (h, h -> chunk_size);\n>> ^~~~~~~~~~~~~\n>> \n>\n> We originally got this from now-discontinued eglibc, but I notice that\n> glibc.git's malloc/obstack.[ch]'s diff also changes these lines. If you\n> backport those do does that fix this warning?\n>\n> I.e. is this another case where we're blindly fixing bugs but should\n> just re-import upstream's code instead?\n\nGood point. I am inclined to queue the remainder of the series\nwithout this one for now.\n\nThanks.\n\n"},{"id":"366550","messageId":"20190111003743.GA840@szeder.dev","threadId":"49576","inReplyTo":"xmqqef9k1a4n.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 1/5] compat/obstack: fix -Wcast-function-type warnings","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-01-11T00:37:43Z","receivedAt":"2019-01-11T00:37:54Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Jan 10, 2019 at 01:22:00PM -0800, Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason writes:\n> \n> > On Thu, Dec 20 2018, SZEDER Gábor wrote:\n> >\n> >> When building Git with GCC 8.2.0 (at least from Homebrew on macOS,\n> >> DEVELOPER flags enabled) one is greeted with a screenful of compiler\n> >> errors:\n> >>\n> >> compat/obstack.c: In function '_obstack_begin':\n> >> compat/obstack.c:162:17: error: cast between incompatible function types from 'void * (*)(long int)' to 'struct _obstack_chunk * (*)(void *, long int)' [-Werror=cast-function-type]\n> >> h->chunkfun = (struct _obstack_chunk * (*)(void *, long)) chunkfun;\n> >> ^\n> >> compat/obstack.c:163:16: error: cast between incompatible function types from 'void (*)(void *)' to 'void (*)(void *, struct _obstack_chunk *)' [-Werror=cast-function-type]\n> >> h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun;\n> >> ^\n> >> compat/obstack.c:116:8: error: cast between incompatible function types from 'struct _obstack_chunk * (*)(void *, long int)' to 'struct _obstack_chunk * (*)(long int)' [-Werror=cast-function-type]\n> >> : (*(struct _obstack_chunk *(*) (long)) (h)->chunkfun) ((size)))\n> >> ^\n> >> compat/obstack.c:168:22: note: in expansion of macro 'CALL_CHUNKFUN'\n> >> chunk = h->chunk = CALL_CHUNKFUN (h, h -> chunk_size);\n> >> ^~~~~~~~~~~~~\n> >> \n> >\n> > We originally got this from now-discontinued eglibc, but I notice that\n> > glibc.git's malloc/obstack.[ch]'s diff also changes these lines. If you\n> > backport those do does that fix this warning?\n> >\n> > I.e. is this another case where we're blindly fixing bugs but should\n> > just re-import upstream's code instead?\n> \n> Good point. I am inclined to queue the remainder of the series\n> without this one for now.\n\nNote that without this first patch the linux-gcc build job will fail\nwith the above compiler error, and that's the only build job that runs\nthe test suite with all the misc test knobs (split-index,\ncommit-graph, etc.) enabled.\n\n"},{"id":"366568","messageId":"xmqq4lafysve.fsf@gitster-ct.c.googlers.com","threadId":"49576","inReplyTo":"20190111003743.GA840@szeder.dev","subject":"Re: [PATCH 1/5] compat/obstack: fix -Wcast-function-type warnings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-01-11T18:03:01Z","receivedAt":"2019-01-11T18:03:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor writes:\n\n> On Thu, Jan 10, 2019 at 01:22:00PM -0800, Junio C Hamano wrote:\n>> Ævar Arnfjörð Bjarmason writes:\n>> ...\n>> > I.e. is this another case where we're blindly fixing bugs but should\n>> > just re-import upstream's code instead?\n>> \n>> Good point. I am inclined to queue the remainder of the series\n>> without this one for now.\n>\n> Note that without this first patch the linux-gcc build job will fail\n> with the above compiler error, and that's the only build job that runs\n> the test suite with all the misc test knobs (split-index,\n> commit-graph, etc.) enabled.\n\nI know. \n\nThe point is to give more incentive to try what was suggested\nearlier by Ævar (in short, \"try to do the right thing, before\nhacking around locally in this project\" ;-)\n"},{"id":"366570","messageId":"20190111185118.GD840@szeder.dev","threadId":"49576","inReplyTo":"xmqq4lafysve.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 1/5] compat/obstack: fix -Wcast-function-type warnings","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-01-11T18:51:18Z","receivedAt":"2019-01-11T18:51:25Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Jan 11, 2019 at 10:03:01AM -0800, Junio C Hamano wrote:\n> SZEDER Gábor writes:\n> \n> > On Thu, Jan 10, 2019 at 01:22:00PM -0800, Junio C Hamano wrote:\n> >> Ævar Arnfjörð Bjarmason writes:\n> >> ...\n> >> > I.e. is this another case where we're blindly fixing bugs but should\n> >> > just re-import upstream's code instead?\n> >> \n> >> Good point. I am inclined to queue the remainder of the series\n> >> without this one for now.\n> >\n> > Note that without this first patch the linux-gcc build job will fail\n> > with the above compiler error, and that's the only build job that runs\n> > the test suite with all the misc test knobs (split-index,\n> > commit-graph, etc.) enabled.\n> \n> I know. \n> \n> The point is to give more incentive to try what was suggested\n> earlier by Ævar (in short, \"try to do the right thing, before\n> hacking around locally in this project\" ;-)\n\nWell, first I'm not sure what changes Ævar meant to be backported.\nBack then I briefly glanced at glibc's gitweb [1], but didn't see\nanything remotely relevant to these compiler errors.\n\nAs to re-importing obstack.{c,h} from upstream, we've made some\nportability fixes to these files, and neither of the commit messages\nof those fixes mention that they are backports from upstream. OTOH,\none of those commits mentions platforms like\n\"i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1, SunOS 5.10\", which makes\nme suspect that the re-import will be susceptible to those portability\nissues again. Therefore, I think re-importing these files from\nupstream is beyond the scope of this patch series (and might not be\nthe right thing at all).\n\n\n[1] https://sourceware.org/git/?p=glibc.git;a=history;f=malloc/obstack.c;h=1669641983512d64f66c1ad659562f77ef48adfd;hb=refs/heads/master\n\n"},{"id":"366785","messageId":"20190115235546.GF840@szeder.dev","threadId":"49576","inReplyTo":"20190111185118.GD840@szeder.dev","subject":"Re: [PATCH 1/5] compat/obstack: fix -Wcast-function-type warnings","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-01-15T23:55:46Z","receivedAt":"2019-01-15T23:55:52Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Jan 11, 2019 at 07:51:18PM +0100, SZEDER Gábor wrote:\n> On Fri, Jan 11, 2019 at 10:03:01AM -0800, Junio C Hamano wrote:\n> > SZEDER Gábor writes:\n> > \n> > > On Thu, Jan 10, 2019 at 01:22:00PM -0800, Junio C Hamano wrote:\n> > >> Ævar Arnfjörð Bjarmason writes:\n> > >> ...\n> > >> > I.e. is this another case where we're blindly fixing bugs but should\n> > >> > just re-import upstream's code instead?\n> > >> \n> > >> Good point. I am inclined to queue the remainder of the series\n> > >> without this one for now.\n> > >\n> > > Note that without this first patch the linux-gcc build job will fail\n> > > with the above compiler error, and that's the only build job that runs\n> > > the test suite with all the misc test knobs (split-index,\n> > > commit-graph, etc.) enabled.\n> > \n> > I know. \n> > \n> > The point is to give more incentive to try what was suggested\n> > earlier by Ævar (in short, \"try to do the right thing, before\n> > hacking around locally in this project\" ;-)\n> \n> Well, first I'm not sure what changes Ævar meant to be backported.\n> Back then I briefly glanced at glibc's gitweb [1], but didn't see\n> anything remotely relevant to these compiler errors.\n\nSo, I looked at the gnulib repository, where glibc got it's\nobstack.{c,h} from, and it does have a fix for this issue in commit\n127ed6a3e (obstack: avoid potentially-nonportable function casts,\n2014-11-04):\n\n http://git.savannah.gnu.org/cgit/gnulib.git/commit?id=127ed6a3ea9c46452f079dee50382dc1f70ea796\n\nIt chose basically the same approach as my fix, i.e. storing pointers\nto functions with different signatures in an union. However,, the\ndifferences between our and their obstack.{c,h} are way too big to\nbackport their patch.\n\n> As to re-importing obstack.{c,h} from upstream, we've made some\n> portability fixes to these files, and neither of the commit messages\n> of those fixes mention that they are backports from upstream. OTOH,\n> one of those commits mentions platforms like\n> \"i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1, SunOS 5.10\", which makes\n> me suspect that the re-import will be susceptible to those portability\n> issues again. Therefore, I think re-importing these files from\n> upstream is beyond the scope of this patch series (and might not be\n> the right thing at all).\n\ngnulib's obstack.{c,h} doesn't fix the issues that we've fixed in\n3254310863 (obstack.c: Fix some sparse warnings, 2011-09-11) and\nd190a0875f (obstack: Fix portability issues, 2011-08-28). So if we\nwere to re-import from gnulib, then these two patches would have to be\napplied on top yet again.\n\n\n> [1] https://sourceware.org/git/?p=glibc.git;a=history;f=malloc/obstack.c;h=1669641983512d64f66c1ad659562f77ef48adfd;hb=refs/heads/master\n> \n"},{"id":"366788","messageId":"20190116011311.GA8864@google.com","threadId":"49576","inReplyTo":"20190115235546.GF840@szeder.dev","subject":"Re: [PATCH 1/5] compat/obstack: fix -Wcast-function-type warnings","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2019-01-16T01:13:11Z","receivedAt":"2019-01-16T01:13:17Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nSZEDER Gábor wrote:\n> On Fri, Jan 11, 2019 at 07:51:18PM +0100, SZEDER Gábor wrote:\n\n>> As to re-importing obstack.{c,h} from upstream, we've made some\n>> portability fixes to these files, and neither of the commit messages\n>> of those fixes mention that they are backports from upstream. OTOH,\n>> one of those commits mentions platforms like\n>> \"i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1, SunOS 5.10\", which makes\n>> me suspect that the re-import will be susceptible to those portability\n>> issues again. Therefore, I think re-importing these files from\n>> upstream is beyond the scope of this patch series (and might not be\n>> the right thing at all).\n>\n> gnulib's obstack.{c,h} doesn't fix the issues that we've fixed in\n> 3254310863 (obstack.c: Fix some sparse warnings, 2011-09-11) and\n> d190a0875f (obstack: Fix portability issues, 2011-08-28). So if we\n> were to re-import from gnulib, then these two patches would have to be\n> applied on top yet again.\n\nThanks for looking into it. The former looks applicable to upstream,\nwhile the latter appears to do some Git-specific things (e.g. relying\non git-compat-util.h).\n\nMind if I send the former upstream? I believe gnulib upstream relies\non copyright assignment, so it would help if you have a copyright\nassignment for the project on file, but if not, they may consider it a\nsmall enough change to take without.\n\nThanks,\nJonathan\n"},{"id":"366796","messageId":"xmqqtvi9nsor.fsf@gitster-ct.c.googlers.com","threadId":"49576","inReplyTo":"20190115235546.GF840@szeder.dev","subject":"Re: [PATCH 1/5] compat/obstack: fix -Wcast-function-type warnings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-01-16T04:16:04Z","receivedAt":"2019-01-16T04:16:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor writes:\n\n>> Well, first I'm not sure what changes Ævar meant to be backported.\n>> Back then I briefly glanced at glibc's gitweb [1], but didn't see\n>> anything remotely relevant to these compiler errors.\n>\n> So, I looked at the gnulib repository, where glibc got it's\n> obstack.{c,h} from, and it does have a fix for this issue in commit\n> 127ed6a3e (obstack: avoid potentially-nonportable function casts,\n> 2014-11-04):\n>\n> http://git.savannah.gnu.org/cgit/gnulib.git/commit?id=127ed6a3ea9c46452f079dee50382dc1f70ea796\n>\n> It chose basically the same approach as my fix, i.e. storing pointers\n> to functions with different signatures in an union. However,, the\n> differences between our and their obstack.{c,h} are way too big to\n> backport their patch.\n\nThanks. In the meantime, I've queued your fix in my tree, and with\nyour digging, we can say we did due diligence and apply a local fix\nwith conscience ;-).\n"},{"id":"366894","messageId":"20190117012913.30562-1-szeder.dev@gmail.com","threadId":"49576","inReplyTo":"20181220162452.17732-1-szeder.dev@gmail.com","subject":"[PATCH v2 0/5] travis-ci: build with the right compiler","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-01-17T01:29:08Z","receivedAt":"2019-01-17T01:29:36Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"\nEver since we started using Travis CI, some of our Travis CI build\njobs don't use the compiler they are supposed to. The last patch\nexplains what's going on and fixes this issue. The first four patches\nare necessary cleanups/fixes to make the fix work.\n\nChanges since v1:\n\n - In patch 1, renamed the fields in the unions holding those\n function pointers to match how gnulib's obstack calls them\n\n http://git.savannah.gnu.org/cgit/gnulib.git/commit?id=127ed6a3ea9c46452f079dee50382dc1f70ea796\n\n - Clarified the commit messages of patches 1 and 5.\n\nv1: https://public-inbox.org/git/20181220162452.17732-1-szeder.dev@gmail.com/T/#u\n\n\nSZEDER Gábor (5):\n compat/obstack: fix -Wcast-function-type warnings\n .gitignore: ignore external debug symbols from GCC on macOS\n travis-ci: don't be '--quiet' when running the tests\n travis-ci: switch to Xcode 10.1 macOS image\n travis-ci: build with the right compiler\n\n .gitignore | 1 +\n .travis.yml | 2 ++\n ci/install-dependencies.sh | 5 +++++\n ci/lib-travisci.sh | 15 ++++++++++++---\n ci/run-build-and-tests.sh | 4 ++--\n ci/run-linux32-build.sh | 2 +-\n compat/obstack.c | 17 +++++++++--------\n compat/obstack.h | 18 +++++++++++-------\n 8 files changed, 43 insertions(+), 21 deletions(-)\n\nRange-diff:\n1: da8f709650 ! 1: be132420c0 compat/obstack: fix -Wcast-function-type warnings\n @@ -2,9 +2,11 @@\n \n compat/obstack: fix -Wcast-function-type warnings\n \n - When building Git with GCC 8.2.0 (at least from Homebrew on macOS,\n - DEVELOPER flags enabled) one is greeted with a screenful of compiler\n - errors:\n + GCC 8 introduced the new -Wcast-function-type warning, which is\n + implied by -Wextra (which, in turn is enabled in our DEVELOPER flags).\n + When building Git with GCC 8 and this warning enabled on a non-glibc\n + platform [1], one is greeted with a screenful of compiler\n + warnings/errors:\n \n compat/obstack.c: In function '_obstack_begin':\n compat/obstack.c:162:17: error: cast between incompatible function types from 'void * (*)(long int)' to 'struct _obstack_chunk * (*)(void *, long int)' [-Werror=cast-function-type]\n @@ -24,9 +26,9 @@\n 'struct obstack' stores pointers to two functions to allocate and free\n \"chunks\", and depending on how obstack is used, these functions take\n either one parameter (like standard malloc() and free() do; this is\n - how we use it) or two parameters. Presumably to reduce memory\n - footprint, a single field is used to store the function pointer for\n - both signatures, and then it's casted to the appropriate signature\n + how we use it in 'kwset.c') or two parameters. Presumably to reduce\n + memory footprint, a single field is used to store the function pointer\n + for both signatures, and then it's casted to the appropriate signature\n when the function pointer is accessed. These casts between function\n pointers with different number of parameters are what trigger those\n compiler errors.\n @@ -37,6 +39,10 @@\n eliminates the need for those casts, and thus avoids this compiler\n error.\n \n + [1] Compiling 'compat/obstack.c' on a platform with glibc is sort of\n + a noop, see the comment before '# define ELIDE_CODE', so this is\n + not an issue on common Linux distros.\n +\n Signed-off-by: SZEDER Gábor \n \n diff --git a/compat/obstack.c b/compat/obstack.c\n @@ -48,17 +54,17 @@\n (((h) -> use_extra_arg) \\\n - ? (*(h)->chunkfun) ((h)->extra_arg, (size)) \\\n - : (*(struct _obstack_chunk *(*) (long)) (h)->chunkfun) ((size)))\n -+ ? (*(h)->chunkfun.fn_extra_arg) ((h)->extra_arg, (size)) \\\n -+ : (*(h)->chunkfun.fn) ((size)))\n ++ ? (*(h)->chunkfun.extra) ((h)->extra_arg, (size)) \\\n ++ : (*(h)->chunkfun.plain) ((size)))\n \n # define CALL_FREEFUN(h, old_chunk) \\\n do { \\\n if ((h) -> use_extra_arg) \\\n - (*(h)->freefun) ((h)->extra_arg, (old_chunk)); \\\n -+ (*(h)->freefun.fn_extra_arg) ((h)->extra_arg, (old_chunk)); \\\n ++ (*(h)->freefun.extra) ((h)->extra_arg, (old_chunk)); \\\n else \\\n - (*(void (*) (void *)) (h)->freefun) ((old_chunk)); \\\n -+ (*(h)->freefun.fn) ((old_chunk)); \\\n ++ (*(h)->freefun.plain) ((old_chunk)); \\\n } while (0)\n \n \f\n @@ -68,8 +74,8 @@\n \n - h->chunkfun = (struct _obstack_chunk * (*)(void *, long)) chunkfun;\n - h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun;\n -+ h->chunkfun.fn = chunkfun;\n -+ h->freefun.fn = freefun;\n ++ h->chunkfun.plain = chunkfun;\n ++ h->freefun.plain = freefun;\n h->chunk_size = size;\n h->alignment_mask = alignment - 1;\n h->use_extra_arg = 0;\n @@ -79,8 +85,8 @@\n \n - h->chunkfun = (struct _obstack_chunk * (*)(void *,long)) chunkfun;\n - h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun;\n -+ h->chunkfun.fn_extra_arg = (struct _obstack_chunk * (*)(void *,long)) chunkfun;\n -+ h->freefun.fn_extra_arg = (void (*) (void *, struct _obstack_chunk *)) freefun;\n ++ h->chunkfun.extra = (struct _obstack_chunk * (*)(void *,long)) chunkfun;\n ++ h->freefun.extra = (void (*) (void *, struct _obstack_chunk *)) freefun;\n +\n h->chunk_size = size;\n h->alignment_mask = alignment - 1;\n @@ -100,12 +106,12 @@\n - void (*freefun) (void *, struct _obstack_chunk *);\n + /* These prototypes vary based on `use_extra_arg'. */\n + union {\n -+ struct _obstack_chunk *(*fn_extra_arg) (void *, long);\n -+ void *(*fn) (long);\n ++ void *(*plain) (long);\n ++ struct _obstack_chunk *(*extra) (void *, long);\n + } chunkfun;\n + union {\n -+ void (*fn_extra_arg) (void *, struct _obstack_chunk *);\n -+ void (*fn) (void *);\n ++ void (*plain) (void *);\n ++ void (*extra) (void *, struct _obstack_chunk *);\n + } freefun;\n void *extra_arg;\t\t/* first arg for chunk alloc/dealloc funcs */\n unsigned use_extra_arg:1;\t/* chunk alloc/dealloc funcs take extra arg */\n @@ -115,11 +121,11 @@\n \n #define obstack_chunkfun(h, newchunkfun) \\\n - ((h) -> chunkfun = (struct _obstack_chunk *(*)(void *, long)) (newchunkfun))\n -+ ((h)->chunkfun.fn_extra_arg = (struct _obstack_chunk *(*)(void *, long)) (newchunkfun))\n ++ ((h)->chunkfun.extra = (struct _obstack_chunk *(*)(void *, long)) (newchunkfun))\n \n #define obstack_freefun(h, newfreefun) \\\n - ((h) -> freefun = (void (*)(void *, struct _obstack_chunk *)) (newfreefun))\n -+ ((h)->freefun.fn_extra_arg = (void (*)(void *, struct _obstack_chunk *)) (newfreefun))\n ++ ((h)->freefun.extra = (void (*)(void *, struct _obstack_chunk *)) (newfreefun))\n \n #define obstack_1grow_fast(h,achar) (*((h)->next_free)++ = (achar))\n \n2: 1f6be06841 = 2: 983e5a4107 .gitignore: ignore external debug symbols from GCC on macOS\n3: 6f6ece8872 = 3: cc3eb12441 travis-ci: don't be '--quiet' when running the tests\n4: a4179caeba = 4: 2155876a85 travis-ci: switch to Xcode 10.1 macOS image\n5: 36323a7c8a ! 5: c91a5bc7ee travis-ci: build with the right compiler\n @@ -3,10 +3,10 @@\n travis-ci: build with the right compiler\n \n Our 'Makefile' hardcodes the compiler to build Git as 'CC = cc'. This\n - can be overridden from the command line, i.e. 'make CC=gcc-X.Y' will\n - build with that particular GCC version, but not from the environment,\n - i.e. 'CC=gcc-X.Y make' will still build with whatever 'cc' happens to\n - be on the platform.\n + CC variable can be overridden from the command line, i.e. 'make\n + CC=gcc-X.Y' will build with that particular GCC version, but not from\n + the environment, i.e. 'CC=gcc-X.Y make' will still build with whatever\n + 'cc' happens to be on the platform.\n \n Our build jobs on Travis CI are badly affected by this. In the build\n matrix we have dedicated build jobs to build Git with GCC and Clang\n-- \n2.20.1.499.gf60de1223c\n\n"},{"id":"366895","messageId":"20190117012913.30562-2-szeder.dev@gmail.com","threadId":"49576","inReplyTo":"20190117012913.30562-1-szeder.dev@gmail.com","subject":"[PATCH v2 1/5] compat/obstack: fix -Wcast-function-type warnings","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-01-17T01:29:09Z","receivedAt":"2019-01-17T01:29:37Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"GCC 8 introduced the new -Wcast-function-type warning, which is\nimplied by -Wextra (which, in turn is enabled in our DEVELOPER flags).\nWhen building Git with GCC 8 and this warning enabled on a non-glibc\nplatform [1], one is greeted with a screenful of compiler\nwarnings/errors:\n\n compat/obstack.c: In function '_obstack_begin':\n compat/obstack.c:162:17: error: cast between incompatible function types from 'void * (*)(long int)' to 'struct _obstack_chunk * (*)(void *, long int)' [-Werror=cast-function-type]\n h->chunkfun = (struct _obstack_chunk * (*)(void *, long)) chunkfun;\n ^\n compat/obstack.c:163:16: error: cast between incompatible function types from 'void (*)(void *)' to 'void (*)(void *, struct _obstack_chunk *)' [-Werror=cast-function-type]\n h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun;\n ^\n compat/obstack.c:116:8: error: cast between incompatible function types from 'struct _obstack_chunk * (*)(void *, long int)' to 'struct _obstack_chunk * (*)(long int)' [-Werror=cast-function-type]\n : (*(struct _obstack_chunk *(*) (long)) (h)->chunkfun) ((size)))\n ^\n compat/obstack.c:168:22: note: in expansion of macro 'CALL_CHUNKFUN'\n chunk = h->chunk = CALL_CHUNKFUN (h, h -> chunk_size);\n ^~~~~~~~~~~~~\n \n\n'struct obstack' stores pointers to two functions to allocate and free\n\"chunks\", and depending on how obstack is used, these functions take\neither one parameter (like standard malloc() and free() do; this is\nhow we use it in 'kwset.c') or two parameters. Presumably to reduce\nmemory footprint, a single field is used to store the function pointer\nfor both signatures, and then it's casted to the appropriate signature\nwhen the function pointer is accessed. These casts between function\npointers with different number of parameters are what trigger those\ncompiler errors.\n\nModify 'struct obstack' to use unions to store function pointers with\ndifferent signatures, and then use the union member with the\nappropriate signature when accessing these function pointers. This\neliminates the need for those casts, and thus avoids this compiler\nerror.\n\n[1] Compiling 'compat/obstack.c' on a platform with glibc is sort of\n a noop, see the comment before '# define ELIDE_CODE', so this is\n not an issue on common Linux distros.\n\nSigned-off-by: SZEDER Gábor \n---\n compat/obstack.c | 17 +++++++++--------\n compat/obstack.h | 18 +++++++++++-------\n 2 files changed, 20 insertions(+), 15 deletions(-)\n\ndiff --git a/compat/obstack.c b/compat/obstack.c\nindex 4d1d95beeb..27cd5c1ea1 100644\n--- a/compat/obstack.c\n+++ b/compat/obstack.c\n@@ -112,15 +112,15 @@ compat_symbol (libc, _obstack_compat, _obstack, GLIBC_2_0);\n \n # define CALL_CHUNKFUN(h, size) \\\n (((h) -> use_extra_arg) \\\n- ? (*(h)->chunkfun) ((h)->extra_arg, (size)) \\\n- : (*(struct _obstack_chunk *(*) (long)) (h)->chunkfun) ((size)))\n+ ? (*(h)->chunkfun.extra) ((h)->extra_arg, (size)) \\\n+ : (*(h)->chunkfun.plain) ((size)))\n \n # define CALL_FREEFUN(h, old_chunk) \\\n do { \\\n if ((h) -> use_extra_arg) \\\n- (*(h)->freefun) ((h)->extra_arg, (old_chunk)); \\\n+ (*(h)->freefun.extra) ((h)->extra_arg, (old_chunk)); \\\n else \\\n- (*(void (*) (void *)) (h)->freefun) ((old_chunk)); \\\n+ (*(h)->freefun.plain) ((old_chunk)); \\\n } while (0)\n \n \f\n@@ -159,8 +159,8 @@ _obstack_begin (struct obstack *h,\n size = 4096 - extra;\n }\n \n- h->chunkfun = (struct _obstack_chunk * (*)(void *, long)) chunkfun;\n- h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun;\n+ h->chunkfun.plain = chunkfun;\n+ h->freefun.plain = freefun;\n h->chunk_size = size;\n h->alignment_mask = alignment - 1;\n h->use_extra_arg = 0;\n@@ -206,8 +206,9 @@ _obstack_begin_1 (struct obstack *h, int size, int alignment,\n size = 4096 - extra;\n }\n \n- h->chunkfun = (struct _obstack_chunk * (*)(void *,long)) chunkfun;\n- h->freefun = (void (*) (void *, struct _obstack_chunk *)) freefun;\n+ h->chunkfun.extra = (struct _obstack_chunk * (*)(void *,long)) chunkfun;\n+ h->freefun.extra = (void (*) (void *, struct _obstack_chunk *)) freefun;\n+\n h->chunk_size = size;\n h->alignment_mask = alignment - 1;\n h->extra_arg = arg;\ndiff --git a/compat/obstack.h b/compat/obstack.h\nindex 6bc24b7644..ced94d0118 100644\n--- a/compat/obstack.h\n+++ b/compat/obstack.h\n@@ -160,11 +160,15 @@ struct obstack\t\t/* control current object in current chunk */\n void *tempptr;\n } temp;\t\t\t/* Temporary for some macros. */\n int alignment_mask;\t\t/* Mask of alignment for each object. */\n- /* These prototypes vary based on `use_extra_arg', and we use\n- casts to the prototypeless function type in all assignments,\n- but having prototypes here quiets -Wstrict-prototypes. */\n- struct _obstack_chunk *(*chunkfun) (void *, long);\n- void (*freefun) (void *, struct _obstack_chunk *);\n+ /* These prototypes vary based on `use_extra_arg'. */\n+ union {\n+ void *(*plain) (long);\n+ struct _obstack_chunk *(*extra) (void *, long);\n+ } chunkfun;\n+ union {\n+ void (*plain) (void *);\n+ void (*extra) (void *, struct _obstack_chunk *);\n+ } freefun;\n void *extra_arg;\t\t/* first arg for chunk alloc/dealloc funcs */\n unsigned use_extra_arg:1;\t/* chunk alloc/dealloc funcs take extra arg */\n unsigned maybe_empty_object:1;/* There is a possibility that the current\n@@ -235,10 +239,10 @@ extern void (*obstack_alloc_failed_handler) (void);\n \t\t (void (*) (void *, void *)) (freefun), (arg))\n \n #define obstack_chunkfun(h, newchunkfun) \\\n- ((h) -> chunkfun = (struct _obstack_chunk *(*)(void *, long)) (newchunkfun))\n+ ((h)->chunkfun.extra = (struct _obstack_chunk *(*)(void *, long)) (newchunkfun))\n \n #define obstack_freefun(h, newfreefun) \\\n- ((h) -> freefun = (void (*)(void *, struct _obstack_chunk *)) (newfreefun))\n+ ((h)->freefun.extra = (void (*)(void *, struct _obstack_chunk *)) (newfreefun))\n \n #define obstack_1grow_fast(h,achar) (*((h)->next_free)++ = (achar))\n \n-- \n2.20.1.499.gf60de1223c\n\n"},{"id":"366896","messageId":"20190117012913.30562-3-szeder.dev@gmail.com","threadId":"49576","inReplyTo":"20190117012913.30562-1-szeder.dev@gmail.com","subject":"[PATCH v2 2/5] .gitignore: ignore external debug symbols from GCC on macOS","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-01-17T01:29:10Z","receivedAt":"2019-01-17T01:29:39Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"When Git is build with a \"real\" GCC on macOS [1], or at least with GCC\ninstalled via Homebrew, and CFLAGS includes the '-g' option (and our\ndefault CFLAGS does), then by default GCC writes the debug symbols\ninto external files under '.dSYM/' directories (e.g.\n'git-daemon.dSYM/', 'git.dSYM/', etc.).\n\nUpdate '.gitignore' to ignore these directories, so they don't clutter\nthe output of 'git status'. Furthermore, these build artifacts then\nwon't trigger build failures on Travis CI via b92cb86ea1 (travis-ci:\ncheck that all build artifacts are .gitignore-d, 2017-12-31) once one\nof the following patches updates our CI build scripts to use a real\nGCC in the 'osx-gcc' build job.\n\n[1] On macOS the default '/usr/bin/gcc' executable is not a real GCC,\n but merely a compatibility wrapper around Clang:\n\n $ gcc --version\n Configured with: --prefix=<...>\n Apple LLVM version 9.0.0 (clang-900.0.39.2)\n <...>\n\n So even though 'make CC=gcc' does indeed execute a command called\n 'gcc', in the end Git will be built with Clang all the same.\n\nSigned-off-by: SZEDER Gábor \n---\n .gitignore | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/.gitignore b/.gitignore\nindex 0d77ea5894..a9db568712 100644\n--- a/.gitignore\n+++ b/.gitignore\n@@ -229,3 +229,4 @@\n *.pdb\n /Debug/\n /Release/\n+*.dSYM\n-- \n2.20.1.499.gf60de1223c\n\n"},{"id":"366897","messageId":"20190117012913.30562-4-szeder.dev@gmail.com","threadId":"49576","inReplyTo":"20190117012913.30562-1-szeder.dev@gmail.com","subject":"[PATCH v2 3/5] travis-ci: don't be '--quiet' when running the tests","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-01-17T01:29:11Z","receivedAt":"2019-01-17T01:29:40Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"All Travis CI build jobs run the test suite with 'make --quiet test'.\n\nOn one hand, being quiet doesn't save us from much clutter in the\noutput:\n\n $ make test |wc -l\n 861\n $ make --quiet test |wc -l\n 848\n\nIt only spares 13 lines, mostly the output of entering the 't/'\ndirectory and the pre- and post-cleanup commands, which is negligible\ncompared to the ~700 lines printed while building Git and the ~850\nlines of 'prove' output.\n\nOn the other hand, it's asking for trouble. In our CI build scripts\nwe build Git and run the test suite in two separate 'make'\ninvocations. In a prelimiary version of one of the later patches in\nthis series, to explicitly specify which compiler to use, I changed\nthem to basically run:\n\n make CC=$CC\n make --quiet test\n\nnaively thinking that it should Just Work... but then that 'make\n--quiet test' got all clever on me, noticed the changed build flags,\nand then proceeded to rebuild everything with the default 'cc'. And\nbecause of that '--quiet' option, it did so, well, quietly, only\nsaying \"* new build flags\", and it was by mere luck that I happened to\nnotice that something is amiss.\n\nLet's just drop that '--quiet' option when running the test suite in\nall build scripts.\n\nSigned-off-by: SZEDER Gábor \n---\n ci/run-build-and-tests.sh | 4 ++--\n ci/run-linux32-build.sh | 2 +-\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex cda170d5c2..84431c097e 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -8,7 +8,7 @@\n ln -s \"$cache_dir/.prove\" t/.prove\n \n make --jobs=2\n-make --quiet test\n+make test\n if test \"$jobname\" = \"linux-gcc\"\n then\n \texport GIT_TEST_SPLIT_INDEX=yes\n@@ -17,7 +17,7 @@ then\n \texport GIT_TEST_OE_DELTA_SIZE=5\n \texport GIT_TEST_COMMIT_GRAPH=1\n \texport GIT_TEST_MULTI_PACK_INDEX=1\n-\tmake --quiet test\n+\tmake test\n fi\n \n check_unignored_build_artifacts\ndiff --git a/ci/run-linux32-build.sh b/ci/run-linux32-build.sh\nindex 2c60d2e70a..26c168a016 100755\n--- a/ci/run-linux32-build.sh\n+++ b/ci/run-linux32-build.sh\n@@ -56,5 +56,5 @@ linux32 --32bit i386 su -m -l $CI_USER -c '\n \tcd /usr/src/git\n \ttest -n \"$cache_dir\" && ln -s \"$cache_dir/.prove\" t/.prove\n \tmake --jobs=2\n-\tmake --quiet test\n+\tmake test\n '\n-- \n2.20.1.499.gf60de1223c\n\n"},{"id":"366898","messageId":"20190117012913.30562-5-szeder.dev@gmail.com","threadId":"49576","inReplyTo":"20190117012913.30562-1-szeder.dev@gmail.com","subject":"[PATCH v2 4/5] travis-ci: switch to Xcode 10.1 macOS image","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-01-17T01:29:12Z","receivedAt":"2019-01-17T01:29:42Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"When building something with GCC installed from Homebrew in the\ndefault macOS (with Xcode 9.4) image on Travis CI, it errors out with\nsomething like this:\n\n /usr/local/Cellar/gcc/8.1.0/lib/gcc/8/gcc/x86_64-apple-darwin17.5.0/8.1.0/include-fixed/stdio.h:78:10: fatal error: _stdio.h: No such file or directory\n #include <_stdio.h>\n ^~~~~~~~~~\n\nThis seems to be a common problem affecting several projects, and the\ncommon solution is to use a Travis CI macOS image with more recent\nXcode version, e.g. 10 or 10.1.\n\nWhile we don't use such a GCC yet, in the very next patch we will, so\nswitch our OSX build jobs to use the Xcode 10.1 image. Compared to\nthe Xcode 10 image, this has the benefit that it comes with GCC (v8.2)\npreinstalled from Homebrew.\n\nSigned-off-by: SZEDER Gábor \n---\n .travis.yml | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/.travis.yml b/.travis.yml\nindex 03c8e4c613..36cbdea7f4 100644\n--- a/.travis.yml\n+++ b/.travis.yml\n@@ -8,6 +8,8 @@ os:\n - linux\n - osx\n \n+osx_image: xcode10.1\n+\n compiler:\n - clang\n - gcc\n-- \n2.20.1.499.gf60de1223c\n\n"},{"id":"366899","messageId":"20190117012913.30562-6-szeder.dev@gmail.com","threadId":"49576","inReplyTo":"20190117012913.30562-1-szeder.dev@gmail.com","subject":"[PATCH v2 5/5] travis-ci: build with the right compiler","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-01-17T01:29:13Z","receivedAt":"2019-01-17T01:29:43Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Our 'Makefile' hardcodes the compiler to build Git as 'CC = cc'. This\nCC variable can be overridden from the command line, i.e. 'make\nCC=gcc-X.Y' will build with that particular GCC version, but not from\nthe environment, i.e. 'CC=gcc-X.Y make' will still build with whatever\n'cc' happens to be on the platform.\n\nOur build jobs on Travis CI are badly affected by this. In the build\nmatrix we have dedicated build jobs to build Git with GCC and Clang\nboth on Linux and macOS from the very beginning (522354d70f (Add\nTravis CI support, 2015-11-27)). Alas, this never really worked as\nsupposed to, because Travis CI specifies the compiler for those build\njobs as 'export CC=gcc' and 'export CC=clang' (which works fine for\nprojects built with './configure && make'). Consequently, our\n'linux-clang' build job has always used GCC, because that's where 'cc'\npoints at in Travis CI's Linux images, while the 'osx-gcc' build job\nhas always used Clang. Furthermore, 37fa4b3c78 (travis-ci: run gcc-8\non linux-gcc jobs, 2018-05-19) added an 'export CC=gcc-8' in an\nattempt to build with a more modern compiler, but to no avail.\n\nSet MAKEFLAGS with CC based on the $CC environment variable, so 'make'\nwill run the \"right\" compiler. The Xcode 10.1 macOS image on Travis\nCI already contains the gcc@8 package from Homebrew, but we have to\n'brew link' it first to be able to use it.\n\nSo with this patch our build jobs will build Git with the following\ncompiler versions:\n\n linux-clang: clang version 5.0.0 (tags/RELEASE_500/final)\n linux-gcc: gcc-8 (Ubuntu 8.1.0-5ubuntu1~14.04) 8.1.0\n\n osx-clang: Apple LLVM version 10.0.0 (clang-1000.11.45.5)\n osx-gcc: gcc-8 (Homebrew GCC 8.2.0) 8.2.0\n\n GETTEXT_POISON: gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4\n\nSigned-off-by: SZEDER Gábor \n---\n ci/install-dependencies.sh | 5 +++++\n ci/lib-travisci.sh | 15 ++++++++++++---\n 2 files changed, 17 insertions(+), 3 deletions(-)\n\ndiff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\nindex 06c3546e1e..dc719876bb 100755\n--- a/ci/install-dependencies.sh\n+++ b/ci/install-dependencies.sh\n@@ -40,6 +40,11 @@ osx-clang|osx-gcc)\n \tbrew install git-lfs gettext\n \tbrew link --force gettext\n \tbrew install caskroom/cask/perforce\n+\tcase \"$jobname\" in\n+\tosx-gcc)\n+\t\tbrew link gcc@8\n+\t\t;;\n+\tesac\n \t;;\n StaticAnalysis)\n \tsudo apt-get -q update\ndiff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh\nindex 69dff4d1ec..a479613a57 100755\n--- a/ci/lib-travisci.sh\n+++ b/ci/lib-travisci.sh\n@@ -99,12 +99,14 @@ export DEFAULT_TEST_TARGET=prove\n export GIT_PROVE_OPTS=\"--timer --jobs 3 --state=failed,slow,save\"\n export GIT_TEST_OPTS=\"--verbose-log -x --immediate\"\n export GIT_TEST_CLONE_2GB=YesPlease\n-if [ \"$jobname\" = linux-gcc ]; then\n-\texport CC=gcc-8\n-fi\n \n case \"$jobname\" in\n linux-clang|linux-gcc)\n+\tif [ \"$jobname\" = linux-gcc ]\n+\tthen\n+\t\texport CC=gcc-8\n+\tfi\n+\n \texport GIT_TEST_HTTPD=YesPlease\n \n \t# The Linux build installs the defined dependency versions below.\n@@ -118,6 +120,11 @@ linux-clang|linux-gcc)\n \texport PATH=\"$GIT_LFS_PATH:$P4_PATH:$PATH\"\n \t;;\n osx-clang|osx-gcc)\n+\tif [ \"$jobname\" = osx-gcc ]\n+\tthen\n+\t\texport CC=gcc-8\n+\tfi\n+\n \t# t9810 occasionally fails on Travis CI OS X\n \t# t9816 occasionally fails with \"TAP out of sequence errors\" on\n \t# Travis CI OS X\n@@ -127,3 +134,5 @@ GIT_TEST_GETTEXT_POISON)\n \texport GIT_TEST_GETTEXT_POISON=YesPlease\n \t;;\n esac\n+\n+export MAKEFLAGS=\"CC=${CC:-cc}\"\n-- \n2.20.1.499.gf60de1223c\n\n"},{"id":"366900","messageId":"20190117013601.GI840@szeder.dev","threadId":"49576","inReplyTo":"20190116011311.GA8864@google.com","subject":"Re: [PATCH 1/5] compat/obstack: fix -Wcast-function-type warnings","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-01-17T01:36:01Z","receivedAt":"2019-01-17T01:36:07Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Jan 15, 2019 at 05:13:11PM -0800, Jonathan Nieder wrote:\n> Hi,\n> \n> SZEDER Gábor wrote:\n> > gnulib's obstack.{c,h} doesn't fix the issues that we've fixed in\n> > 3254310863 (obstack.c: Fix some sparse warnings, 2011-09-11) and\n> > d190a0875f (obstack: Fix portability issues, 2011-08-28). So if we\n> > were to re-import from gnulib, then these two patches would have to be\n> > applied on top yet again.\n> \n> Thanks for looking into it. The former looks applicable to upstream,\n> while the latter appears to do some Git-specific things (e.g. relying\n> on git-compat-util.h).\n> \n> Mind if I send the former upstream?\n\nThat's not my patch, so it doesn't matter whether I mind :) Cc-ing\nRamsay, to make sure.\n\n> I believe gnulib upstream relies\n> on copyright assignment, so it would help if you have a copyright\n> assignment for the project on file, but if not, they may consider it a\n> small enough change to take without.\n> \n> Thanks,\n> Jonathan\n"},{"id":"366989","messageId":"nycvar.QRO.7.76.6.1901171427090.41@tvgsbejvaqbjf.bet","threadId":"49576","inReplyTo":"20190117012913.30562-4-szeder.dev@gmail.com","subject":"Re: [PATCH v2 3/5] travis-ci: don't be '--quiet' when running the tests","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-01-17T13:28:30Z","receivedAt":"2019-01-17T13:28:56Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Gábor,\n\nOn Thu, 17 Jan 2019, SZEDER Gábor wrote:\n\n> All Travis CI build jobs run the test suite with 'make --quiet test'.\n> \n> On one hand, being quiet doesn't save us from much clutter in the\n> output:\n> \n> $ make test |wc -l\n> 861\n> $ make --quiet test |wc -l\n> 848\n> \n> It only spares 13 lines, mostly the output of entering the 't/'\n> directory and the pre- and post-cleanup commands, which is negligible\n> compared to the ~700 lines printed while building Git and the ~850\n> lines of 'prove' output.\n> \n> On the other hand, it's asking for trouble. In our CI build scripts\n> we build Git and run the test suite in two separate 'make'\n> invocations. In a prelimiary version of one of the later patches in\n\ns/prelimiary/preliminary/\n\n> this series, to explicitly specify which compiler to use, I changed\n> them to basically run:\n> \n> make CC=$CC\n> make --quiet test\n> \n> naively thinking that it should Just Work... but then that 'make\n> --quiet test' got all clever on me, noticed the changed build flags,\n> and then proceeded to rebuild everything with the default 'cc'. And\n> because of that '--quiet' option, it did so, well, quietly, only\n> saying \"* new build flags\", and it was by mere luck that I happened to\n> notice that something is amiss.\n> \n> Let's just drop that '--quiet' option when running the test suite in\n> all build scripts.\n> \n> Signed-off-by: SZEDER Gábor \n\nJust like the first two patches, this makes tons of sense to me.\n\nI thank you and will read on,\nDscho\n\n> ---\n> ci/run-build-and-tests.sh | 4 ++--\n> ci/run-linux32-build.sh | 2 +-\n> 2 files changed, 3 insertions(+), 3 deletions(-)\n> \n> diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\n> index cda170d5c2..84431c097e 100755\n> --- a/ci/run-build-and-tests.sh\n> +++ b/ci/run-build-and-tests.sh\n> @@ -8,7 +8,7 @@\n> ln -s \"$cache_dir/.prove\" t/.prove\n> \n> make --jobs=2\n> -make --quiet test\n> +make test\n> if test \"$jobname\" = \"linux-gcc\"\n> then\n> \texport GIT_TEST_SPLIT_INDEX=yes\n> @@ -17,7 +17,7 @@ then\n> \texport GIT_TEST_OE_DELTA_SIZE=5\n> \texport GIT_TEST_COMMIT_GRAPH=1\n> \texport GIT_TEST_MULTI_PACK_INDEX=1\n> -\tmake --quiet test\n> +\tmake test\n> fi\n> \n> check_unignored_build_artifacts\n> diff --git a/ci/run-linux32-build.sh b/ci/run-linux32-build.sh\n> index 2c60d2e70a..26c168a016 100755\n> --- a/ci/run-linux32-build.sh\n> +++ b/ci/run-linux32-build.sh\n> @@ -56,5 +56,5 @@ linux32 --32bit i386 su -m -l $CI_USER -c '\n> \tcd /usr/src/git\n> \ttest -n \"$cache_dir\" && ln -s \"$cache_dir/.prove\" t/.prove\n> \tmake --jobs=2\n> -\tmake --quiet test\n> +\tmake test\n> '\n> -- \n> 2.20.1.499.gf60de1223c\n> \n> "},{"id":"366990","messageId":"nycvar.QRO.7.76.6.1901171439280.41@tvgsbejvaqbjf.bet","threadId":"49576","inReplyTo":"20190117012913.30562-6-szeder.dev@gmail.com","subject":"Re: [PATCH v2 5/5] travis-ci: build with the right compiler","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-01-17T13:44:59Z","receivedAt":"2019-01-17T13:45:22Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Gábor,\n\nOn Thu, 17 Jan 2019, SZEDER Gábor wrote:\n\n> Our 'Makefile' hardcodes the compiler to build Git as 'CC = cc'. This\n> CC variable can be overridden from the command line, i.e. 'make\n> CC=gcc-X.Y' will build with that particular GCC version, but not from\n> the environment, i.e. 'CC=gcc-X.Y make' will still build with whatever\n> 'cc' happens to be on the platform.\n> \n> Our build jobs on Travis CI are badly affected by this. In the build\n> matrix we have dedicated build jobs to build Git with GCC and Clang\n> both on Linux and macOS from the very beginning (522354d70f (Add\n> Travis CI support, 2015-11-27)). Alas, this never really worked as\n> supposed to, because Travis CI specifies the compiler for those build\n> jobs as 'export CC=gcc' and 'export CC=clang' (which works fine for\n> projects built with './configure && make'). Consequently, our\n> 'linux-clang' build job has always used GCC, because that's where 'cc'\n> points at in Travis CI's Linux images, while the 'osx-gcc' build job\n> has always used Clang. Furthermore, 37fa4b3c78 (travis-ci: run gcc-8\n> on linux-gcc jobs, 2018-05-19) added an 'export CC=gcc-8' in an\n> attempt to build with a more modern compiler, but to no avail.\n> \n> Set MAKEFLAGS with CC based on the $CC environment variable, so 'make'\n> will run the \"right\" compiler. The Xcode 10.1 macOS image on Travis\n> CI already contains the gcc@8 package from Homebrew, but we have to\n> 'brew link' it first to be able to use it.\n> \n> So with this patch our build jobs will build Git with the following\n> compiler versions:\n> \n> linux-clang: clang version 5.0.0 (tags/RELEASE_500/final)\n> linux-gcc: gcc-8 (Ubuntu 8.1.0-5ubuntu1~14.04) 8.1.0\n> \n> osx-clang: Apple LLVM version 10.0.0 (clang-1000.11.45.5)\n> osx-gcc: gcc-8 (Homebrew GCC 8.2.0) 8.2.0\n> \n> GETTEXT_POISON: gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4\n> \n> Signed-off-by: SZEDER Gábor \n\nNicely explained and implemented. Thank you!\n\nApart from the single typo I stumbled over (quite honestly, I do not\nreally care about typos, I just point them out when I see them to beat\nEric to it), I have just one more wish: I would *love* to see a Travis\nrun.\n\nSurely you opened a PR at https://github.com/git/git. Oh wait, I can look\nfor it! But no, there does not seem to be one. So probably in your fork,\nhttps://github.com/szeder/git. No PRs. Ah, but there are branches! 60 of\nthem. And yes, I guess I found a Travis build:\n\n\thttps://travis-ci.org/szeder/git/builds/480654256\n\nBut no, the associated branch does not look like it reflects this patch\nseries...\n\nIn any case, this series is:\n\n\tReviewed-by: Johannes Schindelin \n\nCiao,\nDscho\n\n\n> ---\n> ci/install-dependencies.sh | 5 +++++\n> ci/lib-travisci.sh | 15 ++++++++++++---\n> 2 files changed, 17 insertions(+), 3 deletions(-)\n> \n> diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh\n> index 06c3546e1e..dc719876bb 100755\n> --- a/ci/install-dependencies.sh\n> +++ b/ci/install-dependencies.sh\n> @@ -40,6 +40,11 @@ osx-clang|osx-gcc)\n> \tbrew install git-lfs gettext\n> \tbrew link --force gettext\n> \tbrew install caskroom/cask/perforce\n> +\tcase \"$jobname\" in\n> +\tosx-gcc)\n> +\t\tbrew link gcc@8\n> +\t\t;;\n> +\tesac\n> \t;;\n> StaticAnalysis)\n> \tsudo apt-get -q update\n> diff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh\n> index 69dff4d1ec..a479613a57 100755\n> --- a/ci/lib-travisci.sh\n> +++ b/ci/lib-travisci.sh\n> @@ -99,12 +99,14 @@ export DEFAULT_TEST_TARGET=prove\n> export GIT_PROVE_OPTS=\"--timer --jobs 3 --state=failed,slow,save\"\n> export GIT_TEST_OPTS=\"--verbose-log -x --immediate\"\n> export GIT_TEST_CLONE_2GB=YesPlease\n> -if [ \"$jobname\" = linux-gcc ]; then\n> -\texport CC=gcc-8\n> -fi\n> \n> case \"$jobname\" in\n> linux-clang|linux-gcc)\n> +\tif [ \"$jobname\" = linux-gcc ]\n> +\tthen\n> +\t\texport CC=gcc-8\n> +\tfi\n> +\n> \texport GIT_TEST_HTTPD=YesPlease\n> \n> \t# The Linux build installs the defined dependency versions below.\n> @@ -118,6 +120,11 @@ linux-clang|linux-gcc)\n> \texport PATH=\"$GIT_LFS_PATH:$P4_PATH:$PATH\"\n> \t;;\n> osx-clang|osx-gcc)\n> +\tif [ \"$jobname\" = osx-gcc ]\n> +\tthen\n> +\t\texport CC=gcc-8\n> +\tfi\n> +\n> \t# t9810 occasionally fails on Travis CI OS X\n> \t# t9816 occasionally fails with \"TAP out of sequence errors\" on\n> \t# Travis CI OS X\n> @@ -127,3 +134,5 @@ GIT_TEST_GETTEXT_POISON)\n> \texport GIT_TEST_GETTEXT_POISON=YesPlease\n> \t;;\n> esac\n> +\n> +export MAKEFLAGS=\"CC=${CC:-cc}\"\n> -- \n> 2.20.1.499.gf60de1223c\n> \n> "},{"id":"366994","messageId":"20190117145612.GL840@szeder.dev","threadId":"49576","inReplyTo":"nycvar.QRO.7.76.6.1901171439280.41@tvgsbejvaqbjf.bet","subject":"Re: [PATCH v2 5/5] travis-ci: build with the right compiler","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-01-17T14:56:12Z","receivedAt":"2019-01-17T14:56:19Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Jan 17, 2019 at 02:44:59PM +0100, Johannes Schindelin wrote:\n> Hi Gábor,\n> \n> On Thu, 17 Jan 2019, SZEDER Gábor wrote:\n> \n> > Our 'Makefile' hardcodes the compiler to build Git as 'CC = cc'. This\n> > CC variable can be overridden from the command line, i.e. 'make\n> > CC=gcc-X.Y' will build with that particular GCC version, but not from\n> > the environment, i.e. 'CC=gcc-X.Y make' will still build with whatever\n> > 'cc' happens to be on the platform.\n> > \n> > Our build jobs on Travis CI are badly affected by this. In the build\n> > matrix we have dedicated build jobs to build Git with GCC and Clang\n> > both on Linux and macOS from the very beginning (522354d70f (Add\n> > Travis CI support, 2015-11-27)). Alas, this never really worked as\n> > supposed to, because Travis CI specifies the compiler for those build\n> > jobs as 'export CC=gcc' and 'export CC=clang' (which works fine for\n> > projects built with './configure && make'). Consequently, our\n> > 'linux-clang' build job has always used GCC, because that's where 'cc'\n> > points at in Travis CI's Linux images, while the 'osx-gcc' build job\n> > has always used Clang. Furthermore, 37fa4b3c78 (travis-ci: run gcc-8\n> > on linux-gcc jobs, 2018-05-19) added an 'export CC=gcc-8' in an\n> > attempt to build with a more modern compiler, but to no avail.\n> > \n> > Set MAKEFLAGS with CC based on the $CC environment variable, so 'make'\n> > will run the \"right\" compiler. The Xcode 10.1 macOS image on Travis\n> > CI already contains the gcc@8 package from Homebrew, but we have to\n> > 'brew link' it first to be able to use it.\n> > \n> > So with this patch our build jobs will build Git with the following\n> > compiler versions:\n> > \n> > linux-clang: clang version 5.0.0 (tags/RELEASE_500/final)\n> > linux-gcc: gcc-8 (Ubuntu 8.1.0-5ubuntu1~14.04) 8.1.0\n> > \n> > osx-clang: Apple LLVM version 10.0.0 (clang-1000.11.45.5)\n> > osx-gcc: gcc-8 (Homebrew GCC 8.2.0) 8.2.0\n> > \n> > GETTEXT_POISON: gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4\n> > \n> > Signed-off-by: SZEDER Gábor \n> \n> Nicely explained and implemented. Thank you!\n> \n> Apart from the single typo I stumbled over (quite honestly, I do not\n> really care about typos, I just point them out when I see them to beat\n> Eric to it)\n\nHeh ;)\n\n> I have just one more wish: I would *love* to see a Travis\n> run.\n> \n> Surely you opened a PR at https://github.com/git/git. Oh wait, I can look\n> for it! But no, there does not seem to be one.\n\nNope, \"all pull requests are ignored\", so I don't bother.\n\n> So probably in your fork,\n> https://github.com/szeder/git. No PRs. Ah, but there are branches! 60 of\n> them.\n\nOh, wow, 60, that really needs to be cleaned up and all the already\nupstreamed, obsolete, or test branches removed. And, more\nimportantly, my WIP branches finished and finally upstreamed...\nSigh, maybe someday...\n\n> And yes, I guess I found a Travis build:\n> \n> \thttps://travis-ci.org/szeder/git/builds/480654256\n\nThat would be the right build, but it was the result of a rebase\nsquashing a fixup commit and editing commit messages while leaving the\nresulting tree intact, and then 9cc2c76f5e (travis-ci: record and skip\nsuccessfully built trees, 2017-12-31) kicked in and optimized away the\nbuild.\n\nAnyway, I deleted the branch's cache and restarted the build, it will\nmost likely be finished by the time I send this email.\n\n> But no, the associated branch does not look like it reflects this patch\n> series...\n\nThat's the right branch, though, except that it contains a debug patch\non top (that I didn't submitted) that shows the used compiler and its\nversion from within the Makefile, to make sure that the build jobs do\nindeed use the compilers that I think they should be using.\n\nThe other patches on that branch are the same that were submitted in\nthis patch series.\n\n\nHere are the most interesting bits of the problematic build jobs, i.e.\nthe compiler versions from that debug patch:\n\n linux-clang: https://travis-ci.org/szeder/git/jobs/480654257#L824\n osx-gcc: https://travis-ci.org/szeder/git/jobs/480654264#L824\n\n\n> In any case, this series is:\n> \n> \tReviewed-by: Johannes Schindelin \n\nThanks.\n\n"},{"id":"367063","messageId":"nycvar.QRO.7.76.6.1901180940280.41@tvgsbejvaqbjf.bet","threadId":"49576","inReplyTo":"20190117145612.GL840@szeder.dev","subject":"Re: [PATCH v2 5/5] travis-ci: build with the right compiler","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-01-18T08:40:53Z","receivedAt":"2019-01-18T08:41:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Gábor,\n\nOn Thu, 17 Jan 2019, SZEDER Gábor wrote:\n\n> Here are the most interesting bits of the problematic build jobs, i.e.\n> the compiler versions from that debug patch:\n> \n> linux-clang: https://travis-ci.org/szeder/git/jobs/480654257#L824\n> osx-gcc: https://travis-ci.org/szeder/git/jobs/480654264#L824\n\nThanks!\nDscho"}]}