[U-Boot] [RFC PATCH v2 0/2] Make Python scripts compatible with older versions

Stephen Warren swarren at wwwdotorg.org
Mon Aug 11 18:58:45 CEST 2014


On 08/10/2014 02:49 AM, Igor Grinberg wrote:
>
>
> On 08/07/14 20:33, Stephen Warren wrote:
>> On 08/07/2014 10:57 AM, Tom Rini wrote:
>>> On Thu, Aug 07, 2014 at 04:17:21PM +0300, Igor Grinberg wrote:
>>>> On 08/07/14 13:57, Tom Rini wrote:
>> ..
>>>>> we just need
>>>>> /usr/bin/env python2 as how we invoke our scripts.
>>>>
>>>> This means impose python version dependency for U-Boot source build?
>>>> Correct me if you think I'm wrong, but I don't think this is a good
>>>> practice...
>>>> I think that for tools like buildman, patman, etc. - this is
>>>> perfectly fine to impose an interpreter/compiler version, but not
>>>> for the basic source builds.
>>>
>>> I agree.  You don't need MAKEALL or buildman to do basic source builds.
>>> Doing 'make foo_defconfig' doesn't require re-creating boards.cfg.
>>>
>>> To me, the gray area is people doing SoC level (or higher) changes that
>>> want to be good and test more areas.  That's when MAKEALL or buildman
>>> become handy and some sort of win over a shell forloop.
>>
>> Why on earth isn't relying specifically on either Python2 (with the current script code) or Python3 (after porting the code) a good practice?
>
> Because I think (I can think this way, right?) it is not a good practice
> to bring another host machine dependency (moreover, version dependency)
> for the simple source code build (now it also backfired in OE).
>
>> Banning or replacing the use of Python just because they cleaned up their language seems like poking your eye out to spite your nose (or whatever the expression is). The same thing will happen with Perl, and happened with dtc, etc.
>
> Did I say ban python or something? No, I did not say that.

I only see two alternatives:

a) We allow Python to be used to implement parts of the U-Boot build 
process and/or associated utility scripts. This introduces a dependency 
on Python, and such a dependency has to be on a specific (major) version 
of Python because the language in Python2 and Python3 is a bit different.

b) We avoid introducing a dependency on Python by disallowing parts of 
the build process/scripts to be implemented in Python.

> What I'm saying is:
> Right now, we have compiler dependency (a must as you can't practically
> produce any code without it), and we have dtc (a must if you want to
> compile dts), and we have make, and we have shell (this one is found
> on every host, although windows users have to use cygwin or such,
> but who cares, so no problem), and now we also add python to the soup?
>
> Don't get me wrong, I don't have any problem with python...
> I can have any number of python versions I want (I think gentoo is
> the best at supporting this kind of stuff...).
> I just don't think that basic code compile should depend on even more
> stuff being added.
> I've compiled various bootloaders and have seen huge dependencies on
> tools and after all the build time and complexity got worth and worth.
> I don't really want U-Boot to go that direction, but more to keep it
> simple and stupid.

To me, that sounds *exactly* like you're saying ban Python (at least as 
part of the core build process).


More information about the U-Boot mailing list