On Thu, Jan 23, 2020 at 10:39:12PM +0100, Johannes Schindelin wrote: > > diff --git a/ci/lib.sh b/ci/lib.sh > > index a90d0dc0fd..c3a8cd2104 100755 > > --- a/ci/lib.sh > > +++ b/ci/lib.sh > > @@ -162,6 +162,9 @@ linux-clang|linux-gcc) > > if [ "$jobname" = linux-gcc ] > > then > > export CC=gcc-8 > > + MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=$(which python3)" > > + else > > + MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=$(which python2)" > > fi > > > > export GIT_TEST_HTTPD=true > > @@ -182,6 +185,9 @@ osx-clang|osx-gcc) > > if [ "$jobname" = osx-gcc ] > > then > > export CC=gcc-9 > > + MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=$(which python3)" > > + else > > + MAKEFLAGS="$MAKEFLAGS PYTHON_PATH=$(which python2)" > > fi > > > > # t9810 occasionally fails on Travis CI OS X > > My only worry is that this makes it even more obscure what purpose which > job has. Nothing in the name `osx-gcc` shouts loudly "I want to use Python > 3.x!" to me. Do they have to shout that loudly in the name? We could rename these jobs to e.g. 'linux-clang-py2' and the like, but I think it would bring little benefit, if any. In our Travis CI builds these Linux/OSX Clang/GCC jobs come from the build matrix, therefore the jobname is not visible on the Travis CI web interface or API, only in the build logs. There are some pages on Azure Pipelines that do show the jobname (and some that could, but hide it instead), but it's just too convoluted (or sometimes even impossible, well, for me anyway) to get there. And if the requested Python binary can't be found, which will eventually happen with 'python2', then the non-zero exit code of 'which' will abort the build, no matter how the job is called.
