On Thu, Jan 17, 2019 at 02:44:59PM +0100, Johannes Schindelin wrote: > Hi Gábor, > > On Thu, 17 Jan 2019, SZEDER Gábor wrote: > > > Our 'Makefile' hardcodes the compiler to build Git as 'CC = cc'. This > > CC variable can be overridden from the command line, i.e. 'make > > CC=gcc-X.Y' will build with that particular GCC version, but not from > > the environment, i.e. 'CC=gcc-X.Y make' will still build with whatever > > 'cc' happens to be on the platform. > > > > Our build jobs on Travis CI are badly affected by this. In the build > > matrix we have dedicated build jobs to build Git with GCC and Clang > > both on Linux and macOS from the very beginning (522354d70f (Add > > Travis CI support, 2015-11-27)). Alas, this never really worked as > > supposed to, because Travis CI specifies the compiler for those build > > jobs as 'export CC=gcc' and 'export CC=clang' (which works fine for > > projects built with './configure && make'). Consequently, our > > 'linux-clang' build job has always used GCC, because that's where 'cc' > > points at in Travis CI's Linux images, while the 'osx-gcc' build job > > has always used Clang. Furthermore, 37fa4b3c78 (travis-ci: run gcc-8 > > on linux-gcc jobs, 2018-05-19) added an 'export CC=gcc-8' in an > > attempt to build with a more modern compiler, but to no avail. > > > > Set MAKEFLAGS with CC based on the $CC environment variable, so 'make' > > will run the "right" compiler. The Xcode 10.1 macOS image on Travis > > CI already contains the gcc@8 package from Homebrew, but we have to > > 'brew link' it first to be able to use it. > > > > So with this patch our build jobs will build Git with the following > > compiler versions: > > > > linux-clang: clang version 5.0.0 (tags/RELEASE_500/final) > > linux-gcc: gcc-8 (Ubuntu 8.1.0-5ubuntu1~14.04) 8.1.0 > > > > osx-clang: Apple LLVM version 10.0.0 (clang-1000.11.45.5) > > osx-gcc: gcc-8 (Homebrew GCC 8.2.0) 8.2.0 > > > > GETTEXT_POISON: gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 > > > > Signed-off-by: SZEDER Gábor <szeder.dev@xxxxxxxxx> > > Nicely explained and implemented. Thank you! > > Apart from the single typo I stumbled over (quite honestly, I do not > really care about typos, I just point them out when I see them to beat > Eric to it) Heh ;) > I have just one more wish: I would *love* to see a Travis > run. > > Surely you opened a PR at https://github.com/git/git. Oh wait, I can look > for it! But no, there does not seem to be one. Nope, "all pull requests are ignored", so I don't bother. > So probably in your fork, > https://github.com/szeder/git. No PRs. Ah, but there are branches! 60 of > them. Oh, wow, 60, that really needs to be cleaned up and all the already upstreamed, obsolete, or test branches removed. And, more importantly, my WIP branches finished and finally upstreamed... Sigh, maybe someday... > And yes, I guess I found a Travis build: > > https://travis-ci.org/szeder/git/builds/480654256 That would be the right build, but it was the result of a rebase squashing a fixup commit and editing commit messages while leaving the resulting tree intact, and then 9cc2c76f5e (travis-ci: record and skip successfully built trees, 2017-12-31) kicked in and optimized away the build. Anyway, I deleted the branch's cache and restarted the build, it will most likely be finished by the time I send this email. > But no, the associated branch does not look like it reflects this patch > series... That's the right branch, though, except that it contains a debug patch on top (that I didn't submitted) that shows the used compiler and its version from within the Makefile, to make sure that the build jobs do indeed use the compilers that I think they should be using. The other patches on that branch are the same that were submitted in this patch series. Here are the most interesting bits of the problematic build jobs, i.e. the compiler versions from that debug patch: linux-clang: https://travis-ci.org/szeder/git/jobs/480654257#L824 osx-gcc: https://travis-ci.org/szeder/git/jobs/480654264#L824 > In any case, this series is: > > Reviewed-by: Johannes Schindelin <johannes.schindelin@xxxxxx> Thanks.
