in reply to Re^5: Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM?
in thread Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM?

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.

Replies are listed 'Best First'.
Re^7: Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM?
by Anonymous Monk on Feb 18, 2011 at 04:50 UTC
    Can you name a specific platform where setting PERL5LIB in the makefile will be invisible to perl called from within the makefile?

    make syntax isn't exactly universal. Does your syntax work with gmake/dmake/nmake/make/mingw32-make... perl -V:make?

    I would need a portable way to get ExtUtils::MakeMaker to put "projectroot/inc

    use the module inc, it is independent of its father Module::Install

[reply]
[d/l]

      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.

[reply]
[d/l]
[select]
        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

[reply]
[d/l]

In Section Seekers of Perl Wisdom