When I look at an example from the testers, like this one, I do notice that it says "Output from 'C:\Strawberry\c\bin\gmake.exe test':" -- that is, I don't think that the automated testers necessarily do the gmake install -- they might just do the gmake test ... in which case, they wouldn't see the gmake install failure, and thus wouldn't report that failure. I am not confident that seeing passing mswin32 entries necessarily implies that the install step is setup in a portable manner.

Digging into the Makefile.PL, if the file postamble exists, it includes that file as part of the generated Makefile ... and since the distro comes with https://metacpan.org/release/BIGFOOT/Module-ScanDeps-Static-1.7.6/source/postamble , and I don't see anything in the process that would try to delete it, I think they just hardcoded the sh-based assumption for the install step, and didn't even try to be portable.

That must be it, great detective work and explanation. Thanks.

Reported.

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

I think they just hardcoded the sh-based assumption for the install step, and didn't even try to be portable.

Nice work, indeed.
If the 'postamble' file is removed from the source then the module builds, tests and installs just fine on Strawberry.

Cheers,
Rob

From pryrt:

When I look at an example from the testers, like this one, I do notice that it says "Output from 'C:\Strawberry\c\bin\gmake.exe test':" -- that is, I don't think that the automated testers necessarily do the gmake install -- they might just do the gmake test ... in which case, they wouldn't see the gmake install failure, and thus wouldn't report that failure.

I will just echo that this is a fine job of investigating, good clear thinking and asking the right questions. I didn't occur to me that testers don't send in data on the results of (g)make install, so I was left puzzling about what was uniquely wrong with my setup.

One question now remained for me: where does create-modulino.pl come from? In other words, we've seen that the postamble shell code won't work on a MSWin box, but how does it work on Linux/Unix? So, I tried it out, and it's b0rken on Linux too, because create-modulino.pl doesn't exist:

destdir=; \
test -n "$destdir" && destdir="-d $destdir"; \
create-modulino.pl -m Module::ScanDeps::FindRequires \
-a find-requires $destdir -b /usr/local/bin
/bin/sh: 3: create-modulino.pl: not found
make: *** Makefile:1007: install Error 127

    — Soren

Sep 27, 2025 at 17:33 UTC

CLI::Simple is one of the prereqs for Module::ScanDeps::Static . It installs the perl script create-modulino (with no .pl extension) in the bin/ when it install, as shown here. In the previous v0.0.9 of that distro, the bin directory included both the create-modulino and create-modulino.pl -- so with an older version of the CLI::Simple, that postamble in Module::ScanDeps::Static probably would have worked in a linux environment:

Yep, I installed CLI::Simple in my Ubuntu setup, and then installed Module::ScanDeps::Static, and it failed for

destdir=; \
test -n "$destdir" && destdir="-d $destdir"; \
create-modulino.pl -m Module::ScanDeps::FindRequires \
   -a find-requires $destdir -b /home/pryrt/delme/bin
/bin/sh: 3: create-modulino.pl: not found
[download]

Whereas, if I install CLI::Simple@0.0.9 and then Module::ScanDeps::Static, it passed, including the install. So it's definitely caused by the upstream repo not including the .pl version of the script in the bin installation.

The funny thing is, BIGFOOT is the owner of both Module::ScanDeps::Static and CLI::Simple, so should have noticed that changing the prereq would have influenced the postamble of the other distro.

reported