The question is which executable to set?

pryrt's example contains shell code and he said it works on Win.

update

> Who knows if it is honoured when set as an "env" var.

yes the ENV is honored, running dmake inside git-bash works.

I am not convinced my example contains "shell" code.

My guess is that you are thinking it's "shell" code because it's using $(PERLRUN) to reference the variable. But $(PERLRUN) is a makefile variable/macro, not a shell variable. MakeMaker creates a plethora of useful macros in its generated Makefile, so that you have platform independent ways of running common linux-shell-style idioms. It's useful to skim through the auto-generated Makefile to see what's available, and how they define those commands. For example, $(ECHO) will run a command to print to the console, but it might not use your OS's builtin echo command, to avoid compatibility issues.

This super-simplified Makefile.PL works for me:

# dummy makefile

use ExtUtils::MakeMaker;

my %mm_args = (
    'NAME' => 'Dummy::Module',
);

sub MY::postamble {
    return <<'__POSTAMBLE__';

pryrt ::
    $(ECHO) shell is set to "$(SHELL)"
    $(PERL) -V:myuname -V:make

__POSTAMBLE__

}

WriteMakefile( %mm_args );
[download]

then, at the command line, since I have a new enough Strawberry that it uses gmake, I run:

perl Makefile.PL
gmake pryrt
[download]

with the output:

C:\Users\peter.jones\Downloads\TempData\perl>perl Makefile.PL
Generating a gmake-style Makefile
Writing Makefile for Dummy::Module
Writing MYMETA.yml and MYMETA.json

C:\Users\peter.jones\Downloads\TempData\perl>gmake pryrt
"C:\USR\LOCAL\APPS\BERRYBREW\PERLS\SYSTEM\PERL\BIN\perl.exe" -l -e "bi
+nmode STDOUT, qq{:raw}; print qq{@ARGV}" -- shell is set to "C:/Windo
+ws/system32/cmd.exe"
shell is set to C:/Windows/system32/cmd.exe
"C:\USR\LOCAL\APPS\BERRYBREW\PERLS\SYSTEM\PERL\BIN\perl.exe" -V:myunam
+e -V:make
myuname='Win32 strawberry-perl 5.30.0.1 #1 Thu May 23 12:20:46 2019 x6
+4';
make='gmake';
[download]

Notice that the shell is listed as cmd.exe, but the build system is still properly handling $(ECHO) and $(PERL).

I know that I've done similar things with older Strawberry Perl versions (even as far back as v5.10) which used dmake instead of gmake, but I don't have that old of a Strawberry Perl that I can use while at $work, so I cannot prove it right now.

I don't have access to ActiveState Perl nor its build environment. If you want to continue exploring this path, I suggest you try that Makefile.PL and run the sequence with AS's build environment, to see what happens.

> I am not convinced my example contains "shell" code.

I was referring to

skip "rm -rf cover_db"

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

If you run dmake from a CMD (not via git-bash). Then either add a line SHELL=c:...\bash.exe at the beginning of the Makefile (I guess!) or set an windows-ENV var SHELL to point to the bash executable. Of course you need to have that bash.exe somewhere. HTH. Over and out :) I had enough of windows contact for this year!

p.s. Another monk had your woes: Intrepid's scratchpad and seems to have made some progress.

OK, let me rephrase my question ... ;)

Which bash???

If Perl distributions create makefiles with ba/shell code, they must assume that there is either pre-installed shell or that dmake is bundled with some emulation magic.

I know that newer Wins come with a Linux subsystem, but this is older...

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}