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

[Igor Grinberg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/10/14 14:14, Tom Rini wrote:
> On Sun, Aug 10, 2014 at 11:49:12AM +0300, 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.
>> 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?
> 
> Maybe I'm being thick then.  What's the use case you need MAKEALL or
> buildman for?

Now, I feel like we are talking about different things...
I'll try to be a bit more clear on this:

Simple use case: build U-Boot for a board:
================================
$ make mrproper && make cm_t335_config && make -j12 > /dev/null
  CLEAN   examples/standalone
  CLEAN   tools
  CLEAN   u-boot.lds
  CLEAN   spl/arch spl/board spl/common spl/disk spl/drivers spl/fs spl/lib spl/spl spl/u-boot-spl spl/u-boot-spl.bin spl/u-boot-spl.lds spl/u-boot-spl.map
  CLEAN   u-boot.map u-boot.bin u-boot.srec u-boot u-boot.img MLO System.map
  CLEAN   include/generated spl
  CLEAN   include/autoconf.mk include/autoconf.mk.dep include/config.h etags
  HOSTCC  scripts/basic/fixdep
  GEN     /home/grinberg/bin-temp/u-boot/Makefile
  File "/home/grinberg/git-repo/u-boot/scripts/multiconfig.py", line 344
    print "*** Default configuration is based on '%s'" % KBUILD_DEFCONFIG
                                                     ^
SyntaxError: invalid syntax
make[1]: *** [cm_t335_config] Error 1
make: *** [sub-make] Error 2
=======================================

The build failed and I need to either use python 2.7 or patch the
multiconfig.py file. The error message is really not important as
for different system settings (python version) it will differ.
So the above means that for a simple source code build for single board,
one needs to cope with a new dependency... and that is something
I personally dislike.

Another use case: I'm changing common code and I want to send patches,
so I need to make sure I did not break anything.
I run MAKEALL or use buildman to cover relevant/all architectures
and boards. That is perfectly fine with me to use any python
dependency as in this case I use developer tools for achieving the goal.


- -- 
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJT6JiAAAoJEBDE8YO64EfaLFYQAJw9GkzepWD3HoJeo35wayFA
m10O3jekw+W/MxDsBrRlMuq8b03AWT+GRDinDR+tU+ml3nSqIrpqY6wzAG0hO0Gb
NdGi6kCXs+asE0K6umG5j3m+jZ5DNg+ZJC+MQYWXCYaCpv/DUMKcuzOam+crvwiy
miTkJHUsy4mh+0JYg2RDtMugeHSRqz+Hr/9JElbmLVHdetaf/3boJMkoLUzFuu4d
ddLaPWBmSWTUoaccgH1sjswcFflXH3A5+N/SkbTPmCQxBjhmY9m/ehiuictKyqRv
2m4Jk24wq0OrDxlAsoPulWTSdK1cNbXneu1dOVEgPwWveEN3k6ySoTNBdLWgbmoj
KwXPw2h1xe3zv2+ATs4tHY4b3F7WZjBXCFYHe1siFdMvBOefZtTjBLLZo6d9eAef
u6rZAI/SfypCbXbvyxCds4fi3AUkGzJomtSEM7D2t2sXY3YI69rkWpqz85CAtntH
ej8gKwZ4oEx8EWl6y2Yqk3+2f+pirdGjrWVXhUyOy/HDeaJW8YxEe5okw87JWL1m
HDMobXaMIu6XULbjx46lv4v+t8uF1Nb50eGg5xaBtnACOsG0OddFRhHqQypTi5rc
pxI7qCiMND/SYXLAUbRSxxcV5W40WH/A7FKu2KoVZNbAaFX9/gUZrvGVKx4HDOkG
ZuFzuW9AP4AIgw5k4xZI
=mXlx
-----END PGP SIGNATURE-----