Max Reitz <address@hidden> writes:
On 14.05.2014 14:33, Markus Armbruster wrote:
Max Reitz <address@hidden> 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 <address@hidden>
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.
Writing to the source tree works only when the write is exactly the same
for every build tree. Example: autoconf writing configure.
Modifying files under git-control is right out.
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.
A difference between an in-tree and an out-of-tree build is a bug.
If plain "python" is good enough for out-of-tree builds, it should be
good enough for in-tree builds.
As I guess that out-of-tree
builds are actually recommended,
Correct.
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...
I don't know. Try and find out :)
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.
The problem is including generated bits, namely results of configure,
into source files.
The Autoconf way is to substitute placeholders in FOO.in producing FOO.
When you want to limit .in contents as much as possible, you factor out
the stuff that needs substitutions into some SUB.in, which you then
include into FOO. Requires a suitable include mechanism. In shell,
builtin source.
But then you need to find SUB from FOO. I've seen two ways used:
1. Assume SUB is in the current directory. Link FOO into the build tree
to make it so.
2. Require FOO to be run in a way that lets it find its source
directory. If whatever runs FOO puts the full path into argv[0], you
can use that. Else, require a suitable argument or environment
variable.