Sure it will/does :) maybe not the way you hoped/wished/need, but it does

though you still haven't given me a known example where setting PERL5LIB wouldn't work.

Yes, I did, twice. The two posted examples, one using export, the other using :=, wouldn't work with nmake on win32, because := is a syntax error in nmake, and export is not a win32 command or program.

Keep in mind that the kind of person who chooses Makefile.PL over Build.PL isn't terribly convinced that make does have portability problems. On another thread, one poster went so far as to call any advertisement of such concerns as FUD.

Aha, the hyperbole sure sounded familiar.

How about you post the exact scenario you're working with in the form of a patch (diff -ruN empty MinimalExample) and exactly what you hope to accomplish and at which points in the process?

If its only a matter setting @INC for the tests, do it in test.pl, like http://cpansearch.perl.org/src/MARKOV/Mail-Box-2.097/test.pl

Ah... I read the "does it work" literally as a question. Thanks. I haven't used nmake in quite a while. Bless you for the example.

It is indeed only a matter of setting @INC for tests. At least at this stage, I don't forsee ever needing support libraries for anything but testing.

In truth, I had already considered using "test.pl" to set lib and run my scripts. That certainly avoids splatter.

It should have been a three liner (lib, File::Find, Test::Harness::runtests). It worked like a charm when I typed perl ./test.pl on the command line. However, when that same test.pl file was run through "make test" the TAP output never made it to Test::Harness.

I only investigated it superficially, but near as I can tell, it likely had something to do with ExtUtils::MakeMaker::test_harness. It passes test.pl to Test::Harness::runtests. That call of runtests within runtests was probably not something for which Test::Harness was designed.

I quickly concluded that if I couldn't run my tests through runtests, I'd be handcrafting a test runner much like the example you posted. I'd have to study Test::Harness to find out exactly why TAP output is getting swallowed when calls to runtest are nested. Then I'd have to emulate runtest in a way that does not cause that problem.

Then again maybe the solution is much less complex? Perhaps it is nothing more than redirecting or duping STDOUT during test.pl's call to runtest and then dumping that output to STDOUT so that the outer call to runtest saw what it needed? Either way, it is time spent researching and experimenting.

At that point I decided that this was turning into a real programming task and thought it was fair to ask: how important is this really?

Doing it isn't the hard part. Spending my free time all but reinventing the wheel when the need for it seems to be more emotional than practical is what I'm having trouble stomaching. I know there are times when satifying the emotional is important. But its my emotions and time too. I need a good reason.

That's why I posted this: if it really is all that important, I wanted concrete reasons. What I got was "you're a terrible programmer for even wanting to not splatter" and "you're really dumb if you don't realize passthru to Module::Build is crap". Very helpful.

...Doing it isn't the hard part. Spending my free time all but reinventing the wheel when

Or you could have asked how to do it, instead of trawling (fishing) for "concrete reasons" ... :)

See another example http://search.cpan.org/~evo/Class-MakeMethods-1.01/test.pl, the magic part is naming it "tests/*t" instead of "t/*t", works like a charm, there is no TAP swallowing or anything :)