This is 1.11

[perl/modules/Test-Valgrind.git] / lib / Test / Valgrind.pm

diff --git a/lib/Test/Valgrind.pm b/lib/Test/Valgrind.pm
index 28aa6414a7657e7c8844d9824c5e4a2be686c64a..0ca131a922bad6f8b4047a035dc73fe3689bafbf 100644 (file)
--- a/lib/Test/Valgrind.pm
+++ b/lib/Test/Valgrind.pm
@@ -5,15 +5,15 @@ use warnings;
 
 =head1 NAME
 
-Test::Valgrind - Test Perl code through valgrind.
+Test::Valgrind - Generate suppressions, analyse and test any command with valgrind.
 
 =head1 VERSION
 
-Version 1.01
+Version 1.11
 
 =cut
 
-our $VERSION = '1.01';
+our $VERSION = '1.11';
 
 =head1 SYNOPSIS
 
@@ -38,6 +38,9 @@ This module is a front-end to the C<Test::Valgrind::*> API that lets you run Per
 If they aren't available yet, it will first generate suppressions for the current C<perl> interpreter and store them in the portable flavour of F<~/.perl/Test-Valgrind/suppressions/$VERSION>.
 The actual run will then take place, and tests will be passed or failed according to the result of the analysis.
 
+The complete API is much more versatile than this.
+It allows you to run I<any> executable under valgrind, generate the corresponding suppressions and convert the analysis output to TAP so that it can be incorporated into your project's testsuite.
+
 Due to the nature of perl's memory allocator, this module can't track leaks of Perl objects.
 This includes non-mortalized scalars and memory cycles. However, it can track leaks of chunks of memory allocated in XS extensions with C<Newx> and friends or C<malloc>.
 As such, it's complementary to the other very good leak detectors listed in the L</SEE ALSO> section.
@@ -165,7 +168,9 @@ sub analyse {
   );
  };
  unless ($sess) {
-  $action->abort($sess, $@);
+  my $err = $@;
+  $err =~ s/^(Empty valgrind candidates list|No appropriate valgrind executable could be found)\s+at.*/$1/;
+  $action->abort($sess, $err);
   return $action->status($sess);
  }
 
@@ -189,8 +194,8 @@ sub analyse {
 
 =head2 C<import [ %options ]>
 
-In the parent process, L</import> calls L</analyse> with the arguments it received itself - except that if no C<file> option was supplied, it tries to pick the highest caller context that looks like a script.
-When the analyse finishes, it exists with the status that was returned.
+In the parent process, L</import> calls L</analyse> with the arguments it received itself - except that if no C<file> option was supplied, it tries to pick the first caller context that looks like a script.
+When the analyse ends, it exits with the status that was returned.
 
 In the child process, it just C<return>s so that the calling code is actually run under C<valgrind>.
 
@@ -303,14 +308,14 @@ What your tests output to C<STDOUT> and C<STDERR> is eaten unless you pass the C
 
 =head1 DEPENDENCIES
 
-Valgrind 3.1.0 (L<http://valgrind.org>).
-
 L<XML::Twig>, L<version>, L<File::HomeDir>, L<Env::Sanctify>, L<Perl::Destruct::Level>.
 
 =head1 SEE ALSO
 
 All the C<Test::Valgrind::*> API, including L<Test::Valgrind::Command>, L<Test::Valgrind::Tool>, L<Test::Valgrind::Action> and L<Test::Valgrind::Session>.
 
+The C<valgrind(1)> man page.
+
 L<Test::LeakTrace>.
 
 L<Devel::Leak>, L<Devel::LeakTrace>, L<Devel::LeakTrace::Fast>.