in reply to create-modulino.pl appears in a CPAN module Makefile.PL, and nukes the install retval

make is executing the following: 

destdir=; \
test -n "$destdir" && destdir="-d $destdir"; \
create-modulino.pl -m Module::ScanDeps::FindRequires \
   -a find-requires $destdir -b D:/AllSBP\bin

[download]

This is a sh command, but it's being passed to cmd to an unsurprising result. 

C:\>destdir=; \
'destdir' is not recognized as an internal or external command,
operable program or batch file.

[download]

This module's installer isn't portable.

  • Comment on Re: create-modulino.pl appears in a CPAN module Makefile.PL, and nukes the install retval
  • Select or Download Code

Replies are listed 'Best First'.
Re^2: create-modulino.pl appears in a CPAN module Makefile.PL, and nukes the install retval
by choroba (Cardinal) on Sep 25, 2025 at 08:01 UTC
    How comes the testers are fine on MSWin32 and the Makefile.PL doesn't mention destdir at all?

    Update: Added ".PL".

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

      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]
Re^2: create-modulino.pl appears in a CPAN module Makefile.PL, and nukes the install retval
by Intrepid (Curate) on Sep 25, 2025 at 16:34 UTC

    ikegami wisely surmised:

    This is a sh command, but it's being passed to cmd to an unsurprising result.

    Having slept on it, I have come to the conclusion that what you say is correct.

    This module's installer isn't portable.

    Yes–no, it's not portable. I thought I had the kinks worked out of my setup and that win32 perl would handle sh commands but obviously I have not. I'll have to decide how much effort to put into solving that, since I've watched dozens of successful installs from CPAN recently, and this is just one exceptional failure.

        — Soren

    Sep 25, 2025 at 16:34 UTC
[reply]
      If the normal behavior with strawberry is that make commands use cmd, not sh, there may be already fixed distros that rely on that (checking os in Makefile.PL). Futzing your setup to make this one work would then break those; better to just see it as a bug in this distro and change nothing in your setup.
[reply]

        To my knowledge, there's no port of sh available for Windows.

        (There are Cywgin and MSYS binaries, but those run inside of an emulation of unix.)

        One of the motivations for Module::Build was to end the reliance on external OS-specific tools. ExtUtils::MakeMaker relies on make and therefore on external tools or Perl re-implementations of them.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom