|Think about Loose Coupling|
Re^2: Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM?by ELISHEVA (Prior)
|on Feb 17, 2011 at 20:18 UTC||Need Help??|
Nonsense. MM doesn't care one bit....
I think we are misunderstanding each other. MM certainly isn't removing things from @INC or dying if it sees something it doesn't like. I am referring to the contents of @INC before any script calls use lib or any command line sets and exports PERL5LIB.
The contents of that @INC are hard coded to include the usual perl directories + the root of the project + blib/lib + blib/arch. MM generates the "test" target in the makefile using sub test in ExtUtils::MM_Unix (or whatever OS) which inherits from ExtUtils::MM_Any. The generated line in the make file is:
ExtUtils::Command::MM::test_harness adds $(INST_LIB), i.e. blib/lib, and $(INST_ARCHLIB), i.e. blib/arch to @INC. It has no provision for adding anything more to @INC short of completely overriding sub test and generating my own custom test target. I call that hard coding.
I simply don't buy that it is a "good thing" to go around coding "use lib" statements in every single .t file. Module::Build does not make me do it. It gives me a way to make a one line change that automatically ensures that every test and every script knows where to find its support libraries without a single "use lib" statement. Do you really believe the world is a better place if I have to add a line to 16 files rather than one line to one file?
Just like you would have to do with any other script that wants to use uninstalled modules
Um no. Not just like I would do with any other script. To begin with, some of the modules I am thinking of distributing on CPAN get used in other projects that have nothing to do with CPAN (yes I own the IP). I have no need for that "use lib" statement when I run tests on those same modules for those other projects. I have no need of it when I let Module::Build build the project. I only have need of it, if I need it at all, to accommodate MM. I call that building to the tool. I also call that violation of separation of concerns.
I imagine that 100% of testers try to use Makefile.PL, not 3%. They just might not try it first.
I am not proposing doing away with Makefile.PL. Option B keeps Makefile.PL but simply implements the targets with Module::Build rather than ExtUtil::Command::MM. You can still use Makefile.PL to generate a makefile and have it work perfectly if you feel more comfortable that way.
You might well be right that they tried Makefile.PL first. However, in the final analysis, whether they tried it first or not is immaterial. So long as Module::Build is available to try at all, it means that a makefile backed by Module::Build will work.