http://qs1969.pair.com?node_id=11144704


in reply to Better way to force Inline to use compiled binary instead of C source?

Here's an issue I bumped into accidentally, while looking for solution to parent node, but I hesitate to ask a new SOPW question. For Strawberry Perl 5.24 (version to deploy to), even if (and that's confusing part) ExtUtils::MakeMaker is updated to latest CPAN version, the following happens.

Makefile.PL:

use ExtUtils::MakeMaker; WriteMakefile(NAME => 'Test');

Test.pm:

package Test; 1;

running perl Makefile.PL, gmake test results in error:

to undefined at C:/berrybrew/5.24.0.1_64_PDL/perl/site/lib/ExtUtils/In +stall.pm line 1199. makefile:862: recipe for target 'pm_to_blib' failed gmake: *** [pm_to_blib] Error 2

Offending section in Makefile is

# --- MakeMaker pm_to_blib section: pm_to_blib : $(FIRST_MAKEFILE) $(TO_INST_PM) $(NOECHO) $(ABSPERLRUN) -MExtUtils::Install -e "pm_to_blib({{@ARGV +}}, '$(INST_LIB)\auto', q[$(PM_FILTER)], '$(PERM_DIR)')" -- \ Test.pm $(INST_LIB)\Test.pm $(NOECHO) $(TOUCH) pm_to_blib

line #862 contains {{@ARGV}}, deleting a pair of braces (changing double to single) fixes the issue (I peeked at Makefile which is produced under Perl 5.26). It's very confusing, why updating to latest ExtUtils::MakeMaker doesn't help, and how 5.24 is functional at all.

Replies are listed 'Best First'.
Re^2: Better way to force Inline to use compiled binary instead of C source?
by syphilis (Archbishop) on Jun 13, 2022 at 00:31 UTC
    running perl Makefile.PL, gmake test results in error

    This might (untested) be because EU::MM expects the make utility to be "dmake" not "gmake".
    Strawberry made the switch to "gmake" in perl-5.26.0, and have stayed with it since then.

    You might get better mileage with something like:
    use ExtUtils::MakeMaker; WriteMakefile(NAME => 'Test', MAKE => 'gmake' +);
    or just use "dmake" on 5.24.

    Cheers,
    Rob

      Thanks, you are right, either of the 2 solutions fixes the problem.