[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH] iotests: Use configured python
Date: Thu, 15 May 2014 19:29:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 15.05.2014 19:08, Peter Maydell wrote:
On 15 May 2014 17:56, Max Reitz <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]