diff mbox series

[06/14] kbuild: define PYTHON2 and PYTHON3 variables instead of PYTHON

Message ID 1517877294-4826-7-git-send-email-yamada.masahiro@socionext.com
State Superseded
Headers show
Series Add Kconfig unit tests | expand

Commit Message

Masahiro Yamada Feb. 6, 2018, 12:34 a.m. UTC
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 and Python 3 scripts are
used in one system.

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.

arch/ia64/scripts/unwcheck.py is apparently written in Python 2, so
it should be invoked by 'python2'.

It is legitimate to use 'python' for scripts compatible with both
Python 2 and Python 3, but this is rare (at least I do not see the
case in kernel tree).  You do not need to make efforts to write your
scripts in that way.  Anyway, Python 2 will retire in 2020.

This commit is needed for my new scripts written in Python 3.

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

---

 Makefile           | 5 +++--
 arch/ia64/Makefile | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

-- 
2.7.4

Comments

Greg Kroah-Hartman Feb. 6, 2018, 9:34 a.m. UTC | #1
On Tue, Feb 06, 2018 at 09:34:46AM +0900, Masahiro Yamada wrote:
> 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 and Python 3 scripts are

> used in one system.

> 

> 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.

> 

> arch/ia64/scripts/unwcheck.py is apparently written in Python 2, so

> it should be invoked by 'python2'.

> 

> It is legitimate to use 'python' for scripts compatible with both

> Python 2 and Python 3, but this is rare (at least I do not see the

> case in kernel tree).  You do not need to make efforts to write your

> scripts in that way.  Anyway, Python 2 will retire in 2020.

> 

> This commit is needed for my new scripts written in Python 3.

> 

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

> ---

> 

>  Makefile           | 5 +++--

>  arch/ia64/Makefile | 2 +-

>  2 files changed, 4 insertions(+), 3 deletions(-)

> 

> diff --git a/Makefile b/Makefile

> index 11aff0f..c4e935c 100644

> --- a/Makefile

> +++ b/Makefile

> @@ -384,7 +384,8 @@ GENKSYMS	= scripts/genksyms/genksyms

>  INSTALLKERNEL  := installkernel

>  DEPMOD		= /sbin/depmod

>  PERL		= perl

> -PYTHON		= python

> +PYTHON2		= python2

> +PYTHON3		= python3


Is this going to break any systems that were previous setting PYTHON?

I like this change, and feel it is the correct thing to do, but having a
"fallback" might be needed here.

Could you do what the perf makefile does and do something like:
	override PYTHON := $(call get-executable-or-default,PYTHON,$(PYTHON2))
or is it really not an issue as only ia64 seems to care about this?

thanks,

greg k-h
Masahiro Yamada Feb. 6, 2018, 10:44 a.m. UTC | #2
2018-02-06 18:34 GMT+09:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> On Tue, Feb 06, 2018 at 09:34:46AM +0900, Masahiro Yamada wrote:

>> 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 and Python 3 scripts are

>> used in one system.

>>

>> 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.

>>

>> arch/ia64/scripts/unwcheck.py is apparently written in Python 2, so

>> it should be invoked by 'python2'.

>>

>> It is legitimate to use 'python' for scripts compatible with both

>> Python 2 and Python 3, but this is rare (at least I do not see the

>> case in kernel tree).  You do not need to make efforts to write your

>> scripts in that way.  Anyway, Python 2 will retire in 2020.

>>

>> This commit is needed for my new scripts written in Python 3.

>>

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

>> ---

>>

>>  Makefile           | 5 +++--

>>  arch/ia64/Makefile | 2 +-

>>  2 files changed, 4 insertions(+), 3 deletions(-)

>>

>> diff --git a/Makefile b/Makefile

>> index 11aff0f..c4e935c 100644

>> --- a/Makefile

>> +++ b/Makefile

>> @@ -384,7 +384,8 @@ GENKSYMS  = scripts/genksyms/genksyms

>>  INSTALLKERNEL  := installkernel

>>  DEPMOD               = /sbin/depmod

>>  PERL         = perl

>> -PYTHON               = python

>> +PYTHON2              = python2

>> +PYTHON3              = python3

>

> Is this going to break any systems that were previous setting PYTHON?

>

> I like this change, and feel it is the correct thing to do, but having a

> "fallback" might be needed here.

>

> Could you do what the perf makefile does and do something like:

>         override PYTHON := $(call get-executable-or-default,PYTHON,$(PYTHON2))

> or is it really not an issue as only ia64 seems to care about this?

>


As far as I see, ia64 is the only instance that has used this ever.

(the perf Makefile defines PYTHON by itself, so should not be a problem.)


If people expect the backward-compatibility for this, I can do like follows:

# backward compatibility for 'PYTHON'
PYTHON2  := $(if $(PYTHON), $(PYTHON), python2)



Another (unlikely) possible breakage is
'python2' may not be installed on users' system.

I believe this is rare, but if needed, I could do like follows
at the cost of ugliness.


PYTHON2 := $(if $(PYTHON), $(PYTHON), \
        $(shell python2 --version 2>/dev/null && echo python2 || echo python))



-- 
Best Regards
Masahiro Yamada
Greg Kroah-Hartman Feb. 6, 2018, 1:10 p.m. UTC | #3
On Tue, Feb 06, 2018 at 07:44:22PM +0900, Masahiro Yamada wrote:
> 2018-02-06 18:34 GMT+09:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:

> > On Tue, Feb 06, 2018 at 09:34:46AM +0900, Masahiro Yamada wrote:

> >> 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 and Python 3 scripts are

> >> used in one system.

> >>

> >> 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.

> >>

> >> arch/ia64/scripts/unwcheck.py is apparently written in Python 2, so

> >> it should be invoked by 'python2'.

> >>

> >> It is legitimate to use 'python' for scripts compatible with both

> >> Python 2 and Python 3, but this is rare (at least I do not see the

> >> case in kernel tree).  You do not need to make efforts to write your

> >> scripts in that way.  Anyway, Python 2 will retire in 2020.

> >>

> >> This commit is needed for my new scripts written in Python 3.

> >>

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

> >> ---

> >>

> >>  Makefile           | 5 +++--

> >>  arch/ia64/Makefile | 2 +-

> >>  2 files changed, 4 insertions(+), 3 deletions(-)

> >>

> >> diff --git a/Makefile b/Makefile

> >> index 11aff0f..c4e935c 100644

> >> --- a/Makefile

> >> +++ b/Makefile

> >> @@ -384,7 +384,8 @@ GENKSYMS  = scripts/genksyms/genksyms

> >>  INSTALLKERNEL  := installkernel

> >>  DEPMOD               = /sbin/depmod

> >>  PERL         = perl

> >> -PYTHON               = python

> >> +PYTHON2              = python2

> >> +PYTHON3              = python3

> >

> > Is this going to break any systems that were previous setting PYTHON?

> >

> > I like this change, and feel it is the correct thing to do, but having a

> > "fallback" might be needed here.

> >

> > Could you do what the perf makefile does and do something like:

> >         override PYTHON := $(call get-executable-or-default,PYTHON,$(PYTHON2))

> > or is it really not an issue as only ia64 seems to care about this?

> >

> 

> As far as I see, ia64 is the only instance that has used this ever.

> 

> (the perf Makefile defines PYTHON by itself, so should not be a problem.)

> 

> 

> If people expect the backward-compatibility for this, I can do like follows:

> 

> # backward compatibility for 'PYTHON'

> PYTHON2  := $(if $(PYTHON), $(PYTHON), python2)


That's true, and who knows if python3 is running on ia64 :)

> Another (unlikely) possible breakage is

> 'python2' may not be installed on users' system.

> 

> I believe this is rare, but if needed, I could do like follows

> at the cost of ugliness.

> 

> 

> PYTHON2 := $(if $(PYTHON), $(PYTHON), \

>         $(shell python2 --version 2>/dev/null && echo python2 || echo python))


Ick, I guess that might work.  Try getting your patch set into the 0-day
system to see how it handles things.  I know it builds for ia64.

But this is a real tiny question overall, and should not derail this
patchset at all :)

thanks,

greg k-h
Tony Luck Feb. 6, 2018, 5:07 p.m. UTC | #4
> That's true, and who knows if python3 is running on ia64 :)


$ python3
-bash: python3: command not found

So I don't have it installed on my ia64 test/build machine.

-Tony
diff mbox series

Patch

diff --git a/Makefile b/Makefile
index 11aff0f..c4e935c 100644
--- a/Makefile
+++ b/Makefile
@@ -384,7 +384,8 @@  GENKSYMS	= scripts/genksyms/genksyms
 INSTALLKERNEL  := installkernel
 DEPMOD		= /sbin/depmod
 PERL		= perl
-PYTHON		= python
+PYTHON2		= python2
+PYTHON3		= python3
 CHECK		= sparse
 
 CHECKFLAGS     := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
@@ -430,7 +431,7 @@  GCC_PLUGINS_CFLAGS :=
 
 export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
 export CPP AR NM STRIP OBJCOPY OBJDUMP HOSTLDFLAGS HOST_LOADLIBES
-export MAKE LEX YACC AWK GENKSYMS INSTALLKERNEL PERL PYTHON UTS_MACHINE
+export MAKE LEX YACC AWK GENKSYMS INSTALLKERNEL PERL PYTHON2 PYTHON3 UTS_MACHINE
 export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
 
 export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
index 2dd7f51..862a2ba 100644
--- a/arch/ia64/Makefile
+++ b/arch/ia64/Makefile
@@ -75,7 +75,7 @@  vmlinux.gz: vmlinux
 	$(Q)$(MAKE) $(build)=$(boot) $@
 
 unwcheck: vmlinux
-	-$(Q)READELF=$(READELF) $(PYTHON) $(srctree)/arch/ia64/scripts/unwcheck.py $<
+	-$(Q)READELF=$(READELF) $(PYTHON2) $(srctree)/arch/ia64/scripts/unwcheck.py $<
 
 archclean:
 	$(Q)$(MAKE) $(clean)=$(boot)