[U-Boot,RFC] 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(-)

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