StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>To answer the question, you can use Module::Path to check if any of the module files in the distribution are in a <code>blib/lib</code> directory. This is not foolproof because someone might be running <code>prove</code> on the distribution inside another directory called <code>blib</code>, but I think that's unlikely. This also has the disadvantage of requiring that the distribution has a <code>.pm</code> file in it somewhere, which may not be the case.</p> <p>Alternatively, you could check to see if the directory holding the <code>t</code> directory (in a test script this would be <code>$Bin</code> from <code>FindBin</code>) has a <code>blib</code> directory in it. However, if you've run <code>make</code> without <code>make clean</code> and then further developed the script, when you run <code>prove</code> the stale script in the <code>blib</code> directory will still be run.</p> <p>In my comment on my question I mentioned checking <code>$INC{'blib.pm'}</code>. This only works if the test script was called with <code>-Mblib</code>, and <code>make test</code> does not do that. Instead it calls <a href="https://metacpan.org/source/BINGOS/ExtUtils-MakeMaker-6.84/lib/ExtUtils/Command/MM.pm#L53" rel="nofollow"><code>ExtUtils::Command::MM::test_harness</code></a> with <code>blib/lib</code> and <code>blib/arch</code> as include directories. </p> <p>Once you know that you're running code out of blib, then you need to change both the include path, which should be <code>blib/lib</code>, and the script path, which should be <code>blib/script/whatever</code> (and no <code>.pl</code> if your script had one originally, because <code>make</code> removes it). So here's a correct version of the original example:</p> <pre><code>use Module::Path 'module_path'; use Path::Tiny; use FindBin; use Test::More; plan tests => 1; use Capture::Tiny; my $module_path = path(module_path('My::Thing')); my $HAS_BLIB = $module_path #Thing.pm ->parent #My ->parent #lib ->parent #blib ->basename eq 'blib'; my $script_path = $HAS_BLIB && path(qw(blib script my_script)) || path(path($FindBin::Bin)->parent, 'bin', 'my_script.pl'); my $include = $HAS_BLIB && '-Mblib' || # could also do -Iblib/lib -Iblib/arch '-I'. path(path($FindBin::Bin)->parent, 'lib'); # would use installed version of C code my @command = ($^X, $include, $script_path, @batch_files); my ($stdout, $stderr) = capture {system(@command)}; is($stderr, '', 'no errors reported from script'); #more tests here </code></pre> <p>This is an awful lot of trouble, and in this case I don't think that it's necessary. I'm not entirely sure when it would be useful. If your distribution has C/C++ code then you might want to <em>always</em> use the blib solution, which adds blib/arch to the include path. With the above simple example, the test passes using the non-blib settings because the original files are still available. Little change happens to the files copied into the <code>blib</code> directory. So when I was debugging this, the only way I could tell if it was doing the right thing was to print out the full command used! </p> <p>In other words, it wasn't very testable, and if someone really needs this then they should create a module to manage it (and test that). <a href="https://metacpan.org/source/ADAMK/Test-Script-1.07/lib/Test/Script.pm#L116" rel="nofollow">Test::Script</a> seems to always use -Mblib, which would mean you could be using a stale <code>make</code> result, and you have to pass in the path of the script, meaning it's up to you to decide to whether to use the original script or the one inside <code>blib/script</code>.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload