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.

---
 tools/genboardscfg.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 23c956b..fa0f49f 100755
@@ -1,4 +1,4 @@
-#!/usr/bin/env python2
+#!/usr/bin/python2
 #
 # Author: Masahiro Yamada <[email protected]>
 #

1.8.3.1

Hi Wolfgang,

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.

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,

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

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Don't worry about people stealing your ideas. If your ideas are  any
good, you'll have to ram them down people's throats."  - Howard Aiken

Hello Wolfgang,

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