Perl coding error in msvc build system?

I'm not sure whether the following coding actually detects any errors:

Solution.pm:

open(P, "cl /? 2>&1 |") || die "cl command not found";

VSObjectFactory.pm:

open(P, "nmake /? 2>&1 |")
|| croak
"Unable to determine Visual Studio version: The nmake command wasn't found.";

The problem is that because of the shell special characters, the command
is run through the shell, but the shell ignores the exit status of
anything but the last command in the pipe. And the perlopentut man page
says "In such a case, the "open" call will only indicate failure if Perl
can't even run the shell.". I can confirm that on a *nix system. It
might be different on Windows, but it doesn't seem so.

The whole thing could probably be written in a less complicated way
using backticks, like

--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -72,16 +72,13 @@ sub DeterminePlatform

# Examine CL help output to determine if we are in 32 or 64-bit mode.
$self->{platform} = 'Win32';
- open(P, "cl /? 2>&1 |") || die "cl command not found";
- while (<P>)
+ my $output = `cl /? 2>&1`;
+ $? >> 8 == 0 or die "cl command not found";
+ if ($output =~ /^\/favor:<.+AMD64/)
{
- if (/^\/favor:<.+AMD64/)
- {
- $self->{platform} = 'x64';
- last;
- }
+ $self->{platform} = 'x64';
+ last;
}
- close(P);
print "Detected hardware platform: $self->{platform}\n";
}

At 2014-06-03 22:30:50 -0400, peter_e(at)gmx(dot)net wrote:
>
> I'm not sure whether the following coding actually detects any errors:
>
> Solution.pm:
>
> open(P, "cl /? 2>&1 |") || die "cl command not found";

Since nobody with a Windows system has commented, I'm just writing to
say that from a Perl perspective, I agree with your analysis and the
patch looks perfectly sensible.

-- Abhijit

On 01/23/2015 03:17 AM, Abhijit Menon-Sen wrote:
> At 2014-06-03 22:30:50 -0400, peter_e(at)gmx(dot)net wrote:
>> I'm not sure whether the following coding actually detects any errors:
>>
>> Solution.pm:
>>
>> open(P, "cl /? 2>&1 |") || die "cl command not found";
> Since nobody with a Windows system has commented, I'm just writing to
> say that from a Perl perspective, I agree with your analysis and the
> patch looks perfectly sensible.

Not quite. This line:

if ($output =~ /^\/favor:<.+AMD64/)

needs an m modifier on the regex, I think, so that the ^ matches any
beginning of line, not just the first.

cheers

andrew

Why is the "last;" still there? AFAICS it matters in the old coding
because of the while, but I don't think there is an equivalent looping
construct in the new code.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 01/23/2015 03:00 PM, Alvaro Herrera wrote:
> Why is the "last;" still there? AFAICS it matters in the old coding
> because of the while, but I don't think there is an equivalent looping
> construct in the new code.
>

You're right, I missed that. It shouldn't be there, and will produce an
error like

Can't "last" outside a loop block

cheers

andrew

Am 23.01.2015 um 09:17 schrieb Abhijit Menon-Sen:
> At 2014-06-03 22:30:50 -0400, peter_e(at)gmx(dot)net wrote:
>> I'm not sure whether the following coding actually detects any errors:
>>
>> Solution.pm:
>>
>> open(P, "cl /? 2>&1 |") || die "cl command not found";
> Since nobody with a Windows system has commented, I'm just writing to
> say that from a Perl perspective, I agree with your analysis and the
> patch looks perfectly sensible.
>
>
I can confirm it on my Windows system.

Calling build from a console without nmake in the path I always get:
Unable to determine Visual Studio version: The nmake version could not
be determined. at src/tools/msvc/Mkvcbuild.pm line 63.

This means that the following construct in VSObjectFactory.pm doesn't
have the desired effect.
open(P, "nmake /? 2>&1 |")
|| croak
"Unable to determine Visual Studio version: The nmake command wasn't
found.";

On the other hand complicacy is in the eye of the beholder.
Perl constructs like the following get quite a few wtf's
(http://www.osnews.com/story/19266/WTFs_m) from a simple-minded person
like me.
$? >> 8 == 0 or die "cl command not found";

However as it fixes a confirmed problem and as maintainance of perl code
is an issue of its own, please go ahead.

Regards,
Brar

On Fri, Jan 23, 2015 at 4:17 PM, Brar Piening <brar(at)gmx(dot)de> wrote:
> Am 23.01.2015 um 09:17 schrieb Abhijit Menon-Sen:
>> At 2014-06-03 22:30:50 -0400, peter_e(at)gmx(dot)net wrote:
>>> I'm not sure whether the following coding actually detects any errors:
>>>
>>> Solution.pm:
>>>
>>> open(P, "cl /? 2>&1 |") || die "cl command not found";
>>
>> Since nobody with a Windows system has commented, I'm just writing to
>> say that from a Perl perspective, I agree with your analysis and the
>> patch looks perfectly sensible.
>>
>>
> I can confirm it on my Windows system.
>
> Calling build from a console without nmake in the path I always get:
> Unable to determine Visual Studio version: The nmake version could not be
> determined. at src/tools/msvc/Mkvcbuild.pm line 63.
>
> This means that the following construct in VSObjectFactory.pm doesn't have
> the desired effect.
> open(P, "nmake /? 2>&1 |")
> || croak
> "Unable to determine Visual Studio version: The nmake command wasn't
> found.";
>
> On the other hand complicacy is in the eye of the beholder.
> Perl constructs like the following get quite a few wtf's
> (http://www.osnews.com/story/19266/WTFs_m) from a simple-minded person like
> me.
> $? >> 8 == 0 or die "cl command not found";
>
> However as it fixes a confirmed problem and as maintainance of perl code is
> an issue of its own, please go ahead.

This patch been reviewed by 4 people, resulting in 2 minor suggestions
for changes (adding an m modifier, and removing a bogus last).

It has 2 clear upvotes and 0 downvotes.

I think it should be revised along the lines suggested and committed
without further ado.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

> This patch been reviewed by 4 people, resulting in 2 minor suggestions
> for changes (adding an m modifier, and removing a bogus last).
>
> It has 2 clear upvotes and 0 downvotes.
>
> I think it should be revised along the lines suggested and committed
> without further ado.

My patch actually only covered the first of the two faulty locations I
pointed out. Attached is a patch that also fixes the second one. I
noticed that DetermineVisualStudioVersion() is never called with an
argument, so I removed that branch altogether.

On Tue, Feb 17, 2015 at 6:34 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> This patch been reviewed by 4 people, resulting in 2 minor suggestions
>> for changes (adding an m modifier, and removing a bogus last).
>>
>> It has 2 clear upvotes and 0 downvotes.
>>
>> I think it should be revised along the lines suggested and committed
>> without further ado.
>
> My patch actually only covered the first of the two faulty locations I
> pointed out. Attached is a patch that also fixes the second one. I
> noticed that DetermineVisualStudioVersion() is never called with an
> argument, so I removed that branch altogether.

+1 for those simplifications. And FWIW, it passed my series of tests
with MSVC 2010.
--
Michael