X-Git-Url: http://git.vpit.fr/?a=blobdiff_plain;f=lib%2FTest%2FValgrind.pm;h=ea437038640fdb841c0e4ab8ab9556aca2bd8d2d;hb=08860dad1f820cce06758ec4add9353a4dbc8175;hp=28aa6414a7657e7c8844d9824c5e4a2be686c64a;hpb=faf3290acd380f75314a2283314d0a8bcbf97065;p=perl%2Fmodules%2FTest-Valgrind.git

diff --git a/lib/Test/Valgrind.pm b/lib/Test/Valgrind.pm
index 28aa641..ea43703 100644
--- 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.10
 
 =cut
 
-our $VERSION = '1.01';
+our $VERSION = '1.10';
 
 =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>.