Can you name a specific platform where setting PERL5LIB in the makefile will be invisible to perl called from within the makefile?
blib/ExtUtils::testlib simply adds cwd()/blib/arch and cwd()/blib/lib to @INC. "make test" already puts those in @INC. To eliminate the tension between MakeMaker and ModuleBuild without placing all sorts of stuff in the project root, I would need a portable way to get ExtUtils::MakeMaker to put "projectroot/inc", a directory used by [mod://Module::Build], into @INC.
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.