I see. I thought the OP was saying the bit was in Makefile.PL, not Makefile.
The problem is still that a Makefile for unix was generated. Since the testers say it's fine, I'm going to assume it's not File::ShareDir::Install that's non-portable either. Then I suspect some mixes of two OSes was used to build this Makefile. Cygwin, MSYS or MSYS2 was involved. Don't use a unix emulation when you want to install something for Windows.
| [reply] |
I have just a standard Strawberry installation, and I get the same error with the gmake install step that Intrepid showed. (I made sure by resetting my PATH to just include the various %SysetemRoot% directories normally there, and the three strawberry bin paths.) I don't think the problem is on a mixed environment, this time.
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.
| [reply]
[d/l]
[select] |
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]
| [reply]
[d/l] |
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
| [reply] |
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
| [reply] |