in reply to [Win32] Math::GSL on perl 5.10.0

I suspect this is a variation on an old cpan bug-bear of mine.

Instead of just using the string 'perl' in the commands it is going to run and allowing the appropriate executable to be found by the system shell and perl, they get all premature optimise-y about it and insist on trying to find the perl executable's path so they can avoid using the shell by invoking perl directly.

The problem -- if it is the same one -- is that they insist on looking for a perl executable called 'perl' when it will be called 'perl.exe' on Windows.

The only 'fix' (that I found) was to hack your way through the Byzantine maze of pseud--OO configuration scripts to locate the string constant and modify it. The problem is that (IIRC) the bit you need is included from a partial script with a .in extension.

Sorry I cannot be more specific. Nor more sure that this is actually the solution.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: [Win32] Math::GSL on perl 5.10.0
by syphilis (Archbishop) on Nov 04, 2011 at 22:59 UTC
    Nor more sure that this is actually the solution

    Turns out to be the same type of thing - thanks for the pointer.

    Once I searched the Module::Build source for the string "Can't locate the perl binary", it all fell into place fairly quickly.
    In Module/Build/Base.pm there's some checking goes on - looks like they're trying to verify that the perl being used is the first perl to be found in the path. (I don't know why that needs to be done ... I doubt that it does ... but maybe they're trying to check something else altogether...)

    Everything's fine until Base.pm's _quoted_args() sub puts single quotes around C:\MinGW\perl510\bin\perl.exe so that, instead of executing: 
    C:\MinGW\perl510\bin\perl.exe -MConfig=myconfig -e print -e myconfig

    [download]
    this gets executed: 
    'C:\MinGW\perl510\bin\perl.exe' -MConfig=myconfig -e print -e myconfig

    [download]
    which produces the The filename,... error.

    A simple $cmd =~ s/'//g; just prior to the execution of $cmd fixes the problem.
    It's interesting that the same version of Module::Build (ie 0.38) on perls 5.8.0, 5.8.9, 5.12.0 and 5.14.0 does not throw up this problem. I guess there's something specific to 5.10.0 that triggers the error.

    Cheers,
    Rob

    Update: Originally copy'n'pasted the wrong string in a couple of places ... now fixed.
[reply]
[d/l]
[select]
      looks like they're trying to verify that the perl being used is the first perl to be found in the path.

      Still don't get why they don't just let the shell do that job.

      Better still as far as I'm concerned would be to use $^X. That way, if I want to install to a perl other than my default version, I could just invoke it with the full path name from wherever it lives and not have to faff around modifying my path to get it to install in the right place.

      Doesn't $^X work on other platforms?

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
        FWIW, this bug (however stupid) has long big fixed, upgrade Module::Build
[reply]
        That way, if I want to install to a perl other than my default version, I could just invoke it with the full path name from wherever it lives

        Actually, now that I think about it, that's exactly what I was doing at one point (and still getting the same error). At that time, the only perl in my path was the one that resides in MinGW/msys/bin - and I certainly don't want it getting invoked. (MinGW/msys/bin was in the path for other reasons, not because it contained a perl installation ... obviously.)

        So, my guess at the reason for the route that Module::Build takes was probably a bad one.

        Cheers,
        Rob
[reply]

In Section Seekers of Perl Wisdom