On Wed, 02 Feb 2011 at 14:15:07 +0000, Ian Jackson wrote: > So if the tests were in binary packages, often we'd have to construct > a weird binary package which contained all or part of the built source > tree. This would be very ugly and also bulky.
FWIW, Maemo does this, and it's a pain to deal with in practice. Basically nobody writes upstream tests like this, leading to a lot of strange goo in debian/rules: http://gitorious.org/gnome-essentials/dbus-glib/blobs/maemo/debian/rules I think Ian's right, this approach should be avoided. > This is probably going to be > much harder than simply arranging for the tests to test the installed > rather than built copy (if they don't already). For those familiar with Automake or the GNU coding standards, this is the distinction between "make check" (take the uninstalled copy I just compiled, and test it), and "make installcheck" (test the installed version of this package). Automake's "make distcheck" also runs installcheck on the just-installed binaries, if implemented. I get the impression that implementations of installcheck are also quite rare, but telepathy-mission-control-5 is one example of a package that has it. It runs a subset of the "make check" tests on the installed binary. (It's a subset because some of the Mission Control tests require extra hooks in the binary, to manipulate its internal state directly - the "make check" tests run on a modified binary with extra D-Bus interfaces to do that, but the tests relying on this functionality are skipped in "make installcheck" because they wouldn't work.) Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110202150428.ga26...@reptile.pseudorandom.co.uk