Re: [Qemu-devel] [PATCH] iotests: Use configured python

[Max Reitz <mreitz@redhat.com>]

On 15.05.2014 19:08, Peter Maydell wrote:
> On 15 May 2014 17:56, Max Reitz <mreitz@redhat.com> wrote:
>> I think I'll go with Fam's proposal, which is making common.config look for
>> python itself, which then can be overwritten by an environment variable.
> That sounds wrong to me. We already have a way for the user
> to tell us what python to use, which is the configure
> script argument. We should just arrange to use that.

configure (and even make) for me does (do) not create any new file in 
the source tree. If we want to leave it at that, we will need to create 
a configuration file somewhere in the build tree which points to the 
correct version of Python and then tell the iotests where to find that 
file (as the iotests are supposed to be run in the source tree, as far 
as I know). But if we were to do that, the user could easily just 
directly tell it what Python to use.

In fact, the iotests currently have exactly that problem, but not with a 
system program, but with the generated executables. In order to use the 
iotests, one has to create symlinks pointing to the compiled qemu, 
qemu-io, qemu-img and qemu-nbd. This may be because this allows the user 
to freely specify which qemu to use, but I'd much rather guess it is 
exactly because the iotests do not know where the build tree is. 
Otherwise, it would probably default to "$BUILD_PATH/qemu-img" etc. 
instead of just "qemu-img" (i.e. the one in $PATH) if the symlink does 
not exist.

Therefore, I think the iotests have to be independent of configure, as 
they don't appear to have access to configure's results (that is, the 
location of the build tree).

So the user always has some hassle with the iotests, as those symlinks 
have to be created before they may be used. I think this is 
justification enough that we can make the search process for the correct 
Python independent of configure, as long as it is overridable by the 
user (which it would be, through an environment variable).

And finally, if I'll be doing things correctly, it will at least not be 
worse than it currently is. If the user does not specify which Python to 
use for the iotests, common.config will try python2, and if that does 
not exist, python.

I know it would be nice to use the Python which has been selected 
through configure (that is why I wrote the patch like it was in the 
first place), but in order to get the result to iotests, we either have 
to modify the original source tree (where the iotests are run from) or 
tell iotests manually where to find the build tree containing the result.

Max