On Wed, May 12, 2010 at 01:16:33PM +0200, Jim Meyering wrote:
Daniel P. Berrange wrote:
> On Tue, May 11, 2010 at 10:02:01PM +0200, Jim Meyering wrote:
...
>> However, a test that's skipped whenever it detects a running
>> libvirtd is less valuable than one that runs unconditionally,
>> so libvirt-tck is probably the ideal destination.
>>
>> It is critically important to have an easily accessible "make check"-
>> like process that can be used to exercise more of libvirt.
>> I hope libvirt-tck will soon fit the bill.
>
> It already fits that bill & is catching & preventing significant bugs in
> QEMU. It has been invaluable in porting libvirt to the new QEMU JSON
> interface for command & control - it wouldn't have been practical without
> it in fact.
Didn't mean to impugn libvirt-tck. On the contrary, it looks great.
It's just that we need a way to be able to run -- quickly and conveniently --
"make check"-style tests, including integration tests.
Personally I think it is sufficient to just let people invoke the tck command
line tool directly, eg libvirt-tck -c /path/to/config It is not more complex
to invoke that, than invoke a 'make check' command.
If we really need a make command though, it could be done with something like
TCK_CONFIG=$(top_srcdir)/tck.cfg
tck:
$(top_builddir)/daemon/libvirtd --pidfile foo.pid --config blah.cfg
libvirt-tck -c $(TCK_CONFIG)
kill `cat foo.pid`
though this is making assumptions that we need the daemon running for the
tests which is only true for certain URIs. Also, people probably do their
builds as non-root, but its useful to run the tests as root (at least for
qemu:///system or lxc://, but not needed for qemu:///session).
Regards,
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|