RFC Make Python scripts compatible with older versions
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 RFC Latest posting 6/60 of 2 patches 0 repliesNew
- v2 RFC posting 5/60 of 2 patches 0 repliesSuperseded
- v2 RFC posting 4/60 of 2 patches 0 repliesSuperseded
Earlier versions · 3
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v2 RFC posting 3/6 | 0 of 2 patches | 0 replies | Superseded | |
| v2 RFC posting 2/6 | 0 of 2 patches | 0 replies | Superseded | |
| v2 RFC posting 1/6 | 0 of 2 patches | 0 replies | Superseded |
Patches in v2 posting 6/6 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [U-Boot] [RFC PATCH v2 0/2] Make Python scripts compatible with older versions
Quoted 31 lines · Stephen Warren
Quoted 30 lines · Igor Grinberg
Quoted 14 lines · Stephen Warren
Quoted 2 lines · Tom Rini
Quoted 1 line · Igor Grinberg
On 08/07/14 13:57, Tom Rini wrote:
..
Quoted 10 lines
Quoted 9 lines
Quoted 2 lines
we just need
/usr/bin/envpython2 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.Quoted 8 lines
Quoted 6 lines
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).
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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.
I think we can also handle multiple versions support, it will require more thinking and work though...
Quoted 3 lines
b) We avoid introducing a dependency on Python by disallowing parts of the build process/scripts to be implemented in Python.
Why be so strict in choosing the way?
It sounds like we have to choose yes or no.
I would separate the cases and thus let developers use any dependency they like in helper tools/scripts, yet keeping the core build sustained.
Quoted 17 lines
Quoted 7 lines
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?Quoted 9 lines
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.
Quoted 2 lines
To me, that sounds *exactly* like you're saying ban Python (at least as part of the core build process).
Not exactly, but I do want to separate the cases here (at least for now), the core build process and the utility scripting.
For the core build process: currently, I don't think python dependency is needed... It is only the multiconfig.py which was not here until recently. Linux, does not have the python dependency for the core builds... Does Linux core build simpler than U-Boot core build?
Well, of course this is unrelated, but just to get a bit of comparison.
Nevertheless, if we are about to use python in the core build process, the decision must be done in a educated manner and documented appropriately as a dependency (and may be including some documentation or links to description on how to setup the correct version) and not the way it was done, by just sneaking it in (Masahiro, I'm not accusing you, please don't get offended, you've done a great job!).
For the utility scripting: it might be more convenient, and add a lot of power to the scripts, and developers will be very happy to write python stuff, so no problem with that at all. And I think, if that is the case also for java, then I have no problem with that also and will use java... What, I'm saying is that I don't have any particular/personal problem with python.
Signature · 2 lines
Regards, Igor.