[U-Boot] [RFC PATCH] genboardscfg.py: use Python2 from default path
Instead of searching for Python2 in $PATH, use the one installed by the system (i. e. /usr/bin/python2). This prevents failures like this:
-> ./MAKEALL m53evk Traceback (most recent call last): File "tools/genboardscfg.py", line 19, in <module> import fnmatch ImportError: No module named fnmatch Failed to generate boards.cfg
This happens for example with all but the most recent versions of Yocto based tool chains (inclusing all currently existing versions of the ELDK), which provide a python2 binary in SYSROOT/usr/bin/python2, but do not include the "fnmatch" module.
By using the system installed Python interpreter, the user is able to install any missing modules himself, without need to patch and rebuild the whole tool chain.
Signed-off-by: Wolfgang Denk wd@denx.de Cc: Masahiro Yamada yamada.m@jp.panasonic.com --- tools/genboardscfg.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/genboardscfg.py b/tools/genboardscfg.py index 23c956b..fa0f49f 100755 --- a/tools/genboardscfg.py +++ b/tools/genboardscfg.py @@ -1,4 +1,4 @@ -#!/usr/bin/env python2 +#!/usr/bin/python2 # # Author: Masahiro Yamada yamada.m@jp.panasonic.com #
Hi Wolfgang,
On Tue, 30 Sep 2014 10:17:22 +0200 Wolfgang Denk wd@denx.de wrote:
Instead of searching for Python2 in $PATH, use the one installed by the system (i. e. /usr/bin/python2). This prevents failures like this:
-> ./MAKEALL m53evk Traceback (most recent call last): File "tools/genboardscfg.py", line 19, in <module> import fnmatch ImportError: No module named fnmatch Failed to generate boards.cfg
This happens for example with all but the most recent versions of Yocto based tool chains (inclusing all currently existing versions of the ELDK), which provide a python2 binary in SYSROOT/usr/bin/python2, but do not include the "fnmatch" module.
I'd like to regard the root cause of the problem as ELDK missing fnmatch module.
I have no idea if fnmatch module is so special.
By using the system installed Python interpreter, the user is able to install any missing modules himself, without need to patch and rebuild the whole tool chain.
I think '/usr/bin/env python' is a general strategy to support various platforms where Python might not be installed in /usr/bin directory. (Buildman and Patman have already adopted this way.)
If necessary, I do not mind this change (as I only use Linux).
Though FreeBSD people (Jeroen) might be unhappy because the standard installation path of Python is '/usr/local/bin/python' on FreeBSD.
(OK. They can have a symbolic link /usr/bin/python2 => /usr/local/bin/python2)
Best Regards Masahiro Yamada
Dear Masahiro,
In message 20140930175820.4A3C.AA925319@jp.panasonic.com you wrote:
This happens for example with all but the most recent versions of Yocto based tool chains (inclusing all currently existing versions of the ELDK), which provide a python2 binary in SYSROOT/usr/bin/python2, but do not include the "fnmatch" module.
I'd like to regard the root cause of the problem as ELDK missing fnmatch module.
Yes, you are right. The problem is caused by the fact that the ELDK (and other Yocto based tool chains until very recently) provide their own version of Python2, but without including the fnmatch module.
I think '/usr/bin/env python' is a general strategy to support various platforms where Python might not be installed in /usr/bin directory. (Buildman and Patman have already adopted this way.)
I agree, and I'm fully aware of potential issues - this is why I marked this patch as RFC. I'm looking for a solution which works reasonably well for all.
The situation is, that there is a pretty large number of tool chains out there (and ectively being used in a number of projects), which provide their own Python interpreter, but are lacking the fnmatch module.
As I see it, we have the following options to deal with that:
1) Rewrite genboardscfg.py such that fnmatch is not needed. I have no idea if this is easily possible or how much effort was required to do that.
2) Let the script use the system provided Python binary, asuming that fnmatch is either automatically installed or at least ready available and with minimal effort installable in all recent Linux distros.
3) Create fixes so the users can rebuild the tool chains such that these contain the needed Python modules.
4) For all tool chains that support some form of package management, build and distribute the missing Python modules as upate package.
5) Fix and rebuild tool chains and distribute new versions of the tool chains.
My proposed patch choses option 2), as this appears to require the minimal effort on both the tool chain suppliers and on the U-Boot side.
Best regards,
Wolfgang Denk
Hello Wolfgang,
On 30-09-14 10:17, Wolfgang Denk wrote:
Instead of searching for Python2 in $PATH, use the one installed by the system (i. e. /usr/bin/python2). This prevents failures like this:
-> ./MAKEALL m53evk Traceback (most recent call last): File "tools/genboardscfg.py", line 19, in <module> import fnmatch ImportError: No module named fnmatch Failed to generate boards.cfg
This happens for example with all but the most recent versions of Yocto based tool chains (inclusing all currently existing versions of the ELDK), which provide a python2 binary in SYSROOT/usr/bin/python2, but do not include the "fnmatch" module.
By using the system installed Python interpreter, the user is able to install any missing modules himself, without need to patch and rebuild the whole tool chain.
Well lets start with, is this an issue at all? I never run MAKEALL from oe as it taints my environment. Thanks to Masahiro, deployment should not depend on python at all. Developers can install the required python version themselves, even if they don't have root priviliges, since env can pick it up.
Furthermore the tool chains are there to provide the needed tools, so to insist on using the host version is exactly the opposite of what they want to achieve.
Regards, Jeroen
participants (3)
-
Jeroen Hofstee -
Masahiro Yamada -
Wolfgang Denk