inc won't work with make maker. MakeMaker doesn't give the programmer access to @INC and inc needs it. If it did give me access to @INC, I'd never have posted this thread.

As far as I can tell (and no one has yet refuted it), MakeMaker offers only two options: munging PERL5LIB or splattering "use lib" all over the place. Module::Build on the other hand, lets you chose the contents of @INC for all your build tasks. No need to splatter. No need to munge PERL5LIB. If my makefile is backed by Module::Build (via create_makefile_pl => 'small'), I get its ability to control @INC for build tasks. If my makefile is backed by MakeMaker, I get to splatter or munge in a possibly non-portable way.

I share your concerns about make and portability, though you still haven't given me a known example where setting PERL5LIB wouldn't work. A specific example would help to make the decision between option B (use Module::Build to implement make targets - via Module::Build) and eliya's suggestion (munge PERL5LIB and use MakeMaker.

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.

inc won't work with make maker... MakeMaker doesn't give the programmer access to @INC and inc needs it.

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.