]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit - Makefile
kbuild: add PYTHON2 and PYTHON3 variables
authorMasahiro Yamada <yamada.masahiro@socionext.com>
Tue, 13 Mar 2018 09:12:02 +0000 (18:12 +0900)
committerMasahiro Yamada <yamada.masahiro@socionext.com>
Sun, 25 Mar 2018 17:04:01 +0000 (02:04 +0900)
commite9781b52d4e0e3381351d3483cfd173a968dcbe6
tree21632218eefc650bfb0187ba96bd0166b94b38dd
parent2a61625835c7c89c5f00de458a213d59ac54db21
kbuild: add PYTHON2 and PYTHON3 variables

The variable 'PYTHON' allows users to specify a proper executable
name in case the default 'python' does not work.  However, this does
not address the case where both Python 2.x and 3.x scripts are used
in one source tree.

PEP 394 (https://www.python.org/dev/peps/pep-0394/) provides a
convention for Python scripts portability.  Here is a quotation:

  In order to tolerate differences across platforms, all new code
  that needs to invoke the Python interpreter should not specify
  'python', but rather should specify either 'python2' or 'python3'.
  This distinction should be made in shebangs, when invoking from a
  shell script, when invoking via the system() call, or when invoking
  in any other context.
  One exception to this is scripts that are deliberately written to
  be source compatible with both Python 2.x and 3.x. Such scripts may
  continue to use python on their shebang line without affecting their
  portability.

To meet this requirement, this commit adds new variables 'PYTHON2'
and 'PYTHON3'.

arch/ia64/scripts/unwcheck.py is the only script that has ever used
$(PYTHON).  Recent commit bd5edbe67794 ("ia64: convert unwcheck.py to
python3") converted it to be compatible with both Python 2.x and 3.x,
so this is the exceptional case where the use of 'python' is allowed.
So, I did not touch arch/ia64/Makefile.

tools/perf/Makefile.config sets PYTHON and PYTHON2 by itself, so it
is not affected by this commit.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Makefile