On 14.05.2014 14:33, Markus Armbruster wrote:
Max Reitz <mre...@redhat.com> writes:
Currently, QEMU's iotests rely on /usr/bin/env to start the correct
Python (that is, at least Python 2.4, but not 3). On systems where
Python 3 is the default, the user has no clean way of making the iotests
use the correct binary.
This commit makes the iotests use the Python selected by configure.
Signed-off-by: Max Reitz <mre...@redhat.com>
I'm afraid this broke qemu-iotests in a separate build tree:
./check: line 38: ./common.env: No such file or directory
As I already replied to Peter, I see two (or maybe three) ways to fix this:
The first is, we use the correct path to common.env. This would however
result in modification of the source tree although this is probably not
what the user intends with an out-of-tree build. On the other hand, this
would just work.
The second is, we do not create common.env for out-of-tree builds and
add a default common.env to the repository ("PYTHON = python" should
probably suffice). This would not introduce any regressions, however,
the iotests would remain problematic on systems with Python 3 being the
default when using out-of-tree builds. As I guess that out-of-tree
builds are actually recommended, this would mean that the better
solution might be to revert my patch and instead change every "python"
occurrence in the iotests' Shebangs to "python2", as kind of a third way
to go. However, for this I'm not sure whether all systems which are
supposed to be supported by qemu actually have a "python2"
executable/symlink. I guess so, but then again...
So, either we fix it but try to write to the source tree without the
user intending to modify it; or we fix it for in-tree builds only; or we
drop the magic and just use "python2" in the iotests' Shebangs.
Max