#
# set this to point to cmd.exe (only needed if you use some
# alternate shell that doesn't grok cmd.exe style commands)
#
#SHELL        *= g:\winnt\system32\cmd.exe
[download]

SHELL        *= C:\path\to\your_shell.exe
[download]

Plz see Re^4: let Makefile.PL to do the Readme file for me -- new target?, maybe my question becomes clearer then.

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

Plz see Re^4: let Makefile.PL to do the Readme file for me -- new target?

That'd be a waste of time - if my response didn't give you the answer you were looking for then I probably don't have that answer ;-)

Cheers,
Rob

SHELL
    This macro defines the full path to the executable image to be used as the shell when processing single line recipes. This macro must be defined if recipes requiring the shell for execution are to be used. It is assigned a default value in the startup makefile. Under UNIX this value is /bin/sh. 

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

Thanks ... I know this. :)

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.

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

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.

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.