qemu-devel
[Top][All Lists]
Advanced

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

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] iotests: Use configured python
Date: Thu, 15 May 2014 18:33:51 +0100

On 15 May 2014 18:29, Max Reitz <address@hidden> wrote:
> 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.

Yes, and this is correct behaviour. Files created during
build should be created in the build tree. (Consider for
instance a situation where the source tree is being used
to build two configurations simultaneously which have different
--python arguments.)

> 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).

This is the bit I think should be changed. I was surprised to
find that the iotests were not run with their current working
directory set to the build directory, in fact.

> 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.

This also sounds like something that would be simply fixed by
making the current working directory be in the build tree,
not the source tree.

thanks
-- PMM



reply via email to

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