On 2017-11-17 14:15, Cleber Rosa wrote: > > > On 11/17/2017 02:25 AM, Paolo Bonzini wrote: >> On 16/11/2017 18:38, Cleber Rosa wrote: >>> check makes a distinction on how it runs Python based tests. The >>> current approach is inconsistent because: >>> >>> 1) a large number of Python tests are already set as executable files >>> (eg: 030, 040, 041, 044, 045, 055, 056, 057, 065, 093, 118, 147, 149, >>> 155, 165 and 194) >>> >>> 2) a smaller number of Python tests are not set as executable files >>> >>> 3) the true purpose of a shebang line is to make a file executable, >>> while it currently is used (inconsistently) as a test type flag >>> >>> 4) the same logic could in theory be applied to shell based tests, >>> that is, if first line contains a shell shebang, run it with >>> "$SHELL $test_file", but it'd be pointless >>> >>> IMO, there's no value in the distinction that check makes. Dropping >>> this distinction makes the interface simpler: check requires an >>> executable file. >>> >>> Signed-off-by: Cleber Rosa <cr...@redhat.com> >> >> This is quirky, but I think it makes sense to obey the configure >> script's chosen Python interpreter. Unlike /bin/sh or /bin/bash, there >> can be many Python interpreters on a system and the user may not want >> the one in /usr/bin/python (think of old RHEL with software collections, >> even though our use of Python is generally portable to older versions). >> > > Yes, that's a valid point. Looking at it closer, we usually get "python > -B" from configure, so this changes the behavior (can plague the > developer box with .pyc files).
Not just that, the most important thing is that you get python2 on systems where /usr/bin/python points to python3 (i.e., Arch). Max
signature.asc
Description: OpenPGP digital signature