allow running parts of src/tools/msvc/ under not Windows
When making build system changes that risk breaking the MSVC build
system, it's useful to be able to run the part of the MSVC build tools
that read the makefiles and produce the project files under a
not-Windows platform. This part does not really depend on anything
particular to Windows, so it's possible in principle. There are some
minor dependencies on Windows, however, that need to be worked around.
I have had some local hacks for that for a while, and I took a moment to
clean them up and make them presentable, so here they are. Interested?
To test, apply the patch and run perl src/tools/msvc/mkvcbuild.pl .
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Allow-running-src-tools-msvc-mkvcbuild.pl-under-not-.patchtext/plain; charset=UTF-8; name=0001-Allow-running-src-tools-msvc-mkvcbuild.pl-under-not-.patch; x-mac-creator=0; x-mac-type=0Download
From faf9c14893500485beb299e02a9a1374820b9bfd Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Thu, 13 Feb 2020 09:20:57 +0100
Subject: [PATCH] Allow running src/tools/msvc/mkvcbuild.pl under not Windows
This to allow verifying the MSVC build file generation without having
to have Windows.
To do this, we avoid Windows-specific Perl modules and don't run the
"cl" compiler. The resulting build files won't actually be completely
correct, but it's useful enough.
---
src/tools/msvc/Mkvcbuild.pm | 6 ++++--
src/tools/msvc/Project.pm | 2 +-
src/tools/msvc/Solution.pm | 17 ++++++++++++-----
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index a43e31c60e..b9f759a886 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -6,7 +6,7 @@ package Mkvcbuild;
# src/tools/msvc/Mkvcbuild.pm
#
use Carp;
-use Win32;
+use if ($^O eq "MSWin32"), 'Win32';
use strict;
use warnings;
use Project;
@@ -650,9 +650,11 @@ sub mkvcbuild
# 'Can't spawn "conftest.exe"'; suppress that.
no warnings;
+ no strict 'subs';
+
# Disable error dialog boxes like we do in the postmaster.
# Here, we run code that triggers relevant errors.
- use Win32API::File qw(SetErrorMode :SEM_);
+ use if ($^O eq "MSWin32"), 'Win32API::File', qw(SetErrorMode :SEM_);
my $oldmode = SetErrorMode(
SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
system(".\\$exe");
diff --git a/src/tools/msvc/Project.pm b/src/tools/msvc/Project.pm
index 7d25704e2c..d90a996d46 100644
--- a/src/tools/msvc/Project.pm
+++ b/src/tools/msvc/Project.pm
@@ -22,7 +22,7 @@ sub _new
my $self = {
name => $name,
type => $type,
- guid => Win32::GuidGen(),
+ guid => $^O eq "MSWin32" ? Win32::GuidGen() : 'FAKE',
files => {},
references => [],
libraries => [],
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 8412ef298e..68c1ebb833 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -60,10 +60,17 @@ sub DeterminePlatform
{
my $self = shift;
- # Examine CL help output to determine if we are in 32 or 64-bit mode.
- my $output = `cl /? 2>&1`;
- $? >> 8 == 0 or die "cl command not found";
- $self->{platform} = ($output =~ /^\/favor:<.+AMD64/m) ? 'x64' : 'Win32';
+ if ($^O eq "MSWin32")
+ {
+ # Examine CL help output to determine if we are in 32 or 64-bit mode.
+ my $output = `cl /? 2>&1`;
+ $? >> 8 == 0 or die "cl command not found";
+ $self->{platform} = ($output =~ /^\/favor:<.+AMD64/m) ? 'x64' : 'Win32';
+ }
+ else
+ {
+ $self->{platform} = 'FAKE';
+ }
print "Detected hardware platform: $self->{platform}\n";
return;
}
@@ -1081,7 +1088,7 @@ EOF
}
if ($fld ne "")
{
- $flduid{$fld} = Win32::GuidGen();
+ $flduid{$fld} = $^O eq "MSWin32" ? Win32::GuidGen() : 'FAKE';
print $sln <<EOF;
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "$fld", "$fld", "$flduid{$fld}"
EndProject
--
2.25.0
On Thu, Feb 13, 2020 at 12:00:54PM +0100, Peter Eisentraut wrote:
When making build system changes that risk breaking the MSVC build system,
it's useful to be able to run the part of the MSVC build tools that read the
makefiles and produce the project files under a not-Windows platform. This
part does not really depend on anything particular to Windows, so it's
possible in principle. There are some minor dependencies on Windows,
however, that need to be worked around. I have had some local hacks for that
for a while, and I took a moment to clean them up and make them presentable,
so here they are. Interested?To test, apply the patch and run perl src/tools/msvc/mkvcbuild.pl .
$ perl src/tools/msvc/mkvcbuild.pl .
Warning: no config.pl found, using default.
Unable to determine Visual Studio version: The nmake command wasn't
found. at /home/ioltas/git/postgres/src/tools/msvc/Mkvcbuild.pm line 92.
Is that the expected result?
--
Michael
On 2020-02-13 13:04, Michael Paquier wrote:
On Thu, Feb 13, 2020 at 12:00:54PM +0100, Peter Eisentraut wrote:
When making build system changes that risk breaking the MSVC build system,
it's useful to be able to run the part of the MSVC build tools that read the
makefiles and produce the project files under a not-Windows platform. This
part does not really depend on anything particular to Windows, so it's
possible in principle. There are some minor dependencies on Windows,
however, that need to be worked around. I have had some local hacks for that
for a while, and I took a moment to clean them up and make them presentable,
so here they are. Interested?To test, apply the patch and run perl src/tools/msvc/mkvcbuild.pl .
$ perl src/tools/msvc/mkvcbuild.pl .
Warning: no config.pl found, using default.
Unable to determine Visual Studio version: The nmake command wasn't
found. at /home/ioltas/git/postgres/src/tools/msvc/Mkvcbuild.pm line 92.
Is that the expected result?
No, I had apparently created by own fake "nmake" shell script some time
ago to work around that. Here is a new patch with that taken care of, too.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
v2-0001-Allow-running-src-tools-msvc-mkvcbuild.pl-under-n.patchtext/plain; charset=UTF-8; name=v2-0001-Allow-running-src-tools-msvc-mkvcbuild.pl-under-n.patch; x-mac-creator=0; x-mac-type=0Download
From 4b09d5c766dfacace9973b5d0f38d453537149b3 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Thu, 13 Feb 2020 14:22:46 +0100
Subject: [PATCH v2] Allow running src/tools/msvc/mkvcbuild.pl under not
Windows
This to allow verifying the MSVC build file generation without having
to have Windows.
To do this, we avoid Windows-specific Perl modules and don't run the
"cl" compiler. The resulting build files won't actually be completely
correct, but it's useful enough.
---
src/tools/msvc/Mkvcbuild.pm | 6 ++++--
src/tools/msvc/Project.pm | 2 +-
src/tools/msvc/Solution.pm | 17 ++++++++++++-----
src/tools/msvc/VSObjectFactory.pm | 31 +++++++++++++++++++------------
4 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index a43e31c60e..b9f759a886 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -6,7 +6,7 @@ package Mkvcbuild;
# src/tools/msvc/Mkvcbuild.pm
#
use Carp;
-use Win32;
+use if ($^O eq "MSWin32"), 'Win32';
use strict;
use warnings;
use Project;
@@ -650,9 +650,11 @@ sub mkvcbuild
# 'Can't spawn "conftest.exe"'; suppress that.
no warnings;
+ no strict 'subs';
+
# Disable error dialog boxes like we do in the postmaster.
# Here, we run code that triggers relevant errors.
- use Win32API::File qw(SetErrorMode :SEM_);
+ use if ($^O eq "MSWin32"), 'Win32API::File', qw(SetErrorMode :SEM_);
my $oldmode = SetErrorMode(
SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
system(".\\$exe");
diff --git a/src/tools/msvc/Project.pm b/src/tools/msvc/Project.pm
index 7d25704e2c..d90a996d46 100644
--- a/src/tools/msvc/Project.pm
+++ b/src/tools/msvc/Project.pm
@@ -22,7 +22,7 @@ sub _new
my $self = {
name => $name,
type => $type,
- guid => Win32::GuidGen(),
+ guid => $^O eq "MSWin32" ? Win32::GuidGen() : 'FAKE',
files => {},
references => [],
libraries => [],
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 8412ef298e..68c1ebb833 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -60,10 +60,17 @@ sub DeterminePlatform
{
my $self = shift;
- # Examine CL help output to determine if we are in 32 or 64-bit mode.
- my $output = `cl /? 2>&1`;
- $? >> 8 == 0 or die "cl command not found";
- $self->{platform} = ($output =~ /^\/favor:<.+AMD64/m) ? 'x64' : 'Win32';
+ if ($^O eq "MSWin32")
+ {
+ # Examine CL help output to determine if we are in 32 or 64-bit mode.
+ my $output = `cl /? 2>&1`;
+ $? >> 8 == 0 or die "cl command not found";
+ $self->{platform} = ($output =~ /^\/favor:<.+AMD64/m) ? 'x64' : 'Win32';
+ }
+ else
+ {
+ $self->{platform} = 'FAKE';
+ }
print "Detected hardware platform: $self->{platform}\n";
return;
}
@@ -1081,7 +1088,7 @@ EOF
}
if ($fld ne "")
{
- $flduid{$fld} = Win32::GuidGen();
+ $flduid{$fld} = $^O eq "MSWin32" ? Win32::GuidGen() : 'FAKE';
print $sln <<EOF;
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "$fld", "$fld", "$flduid{$fld}"
EndProject
diff --git a/src/tools/msvc/VSObjectFactory.pm b/src/tools/msvc/VSObjectFactory.pm
index 610dc61286..e6983b241f 100644
--- a/src/tools/msvc/VSObjectFactory.pm
+++ b/src/tools/msvc/VSObjectFactory.pm
@@ -111,21 +111,28 @@ sub CreateProject
sub DetermineVisualStudioVersion
{
+ if ($^O eq "MSWin32")
+ {
+ # To determine version of Visual Studio we use nmake as it has
+ # existed for a long time and still exists in current Visual
+ # Studio versions.
+ my $output = `nmake /? 2>&1`;
+ $? >> 8 == 0
+ or croak
+ "Unable to determine Visual Studio version: The nmake command wasn't found.";
+ if ($output =~ /(\d+)\.(\d+)\.\d+(\.\d+)?$/m)
+ {
+ return _GetVisualStudioVersion($1, $2);
+ }
- # To determine version of Visual Studio we use nmake as it has
- # existed for a long time and still exists in current Visual
- # Studio versions.
- my $output = `nmake /? 2>&1`;
- $? >> 8 == 0
- or croak
- "Unable to determine Visual Studio version: The nmake command wasn't found.";
- if ($output =~ /(\d+)\.(\d+)\.\d+(\.\d+)?$/m)
+ croak
+ "Unable to determine Visual Studio version: The nmake version could not be determined.";
+ }
+ else
{
- return _GetVisualStudioVersion($1, $2);
+ # fake version
+ return '16.00';
}
-
- croak
- "Unable to determine Visual Studio version: The nmake version could not be determined.";
}
sub _GetVisualStudioVersion
--
2.25.0
On Thu, Feb 13, 2020 at 02:24:43PM +0100, Peter Eisentraut wrote:
On 2020-02-13 13:04, Michael Paquier wrote:
On Thu, Feb 13, 2020 at 12:00:54PM +0100, Peter Eisentraut wrote:
When making build system changes that risk breaking the MSVC build system,
it's useful to be able to run the part of the MSVC build tools that read the
makefiles and produce the project files under a not-Windows platform. This
part does not really depend on anything particular to Windows, so it's
possible in principle. There are some minor dependencies on Windows,
however, that need to be worked around. I have had some local hacks for that
for a while, and I took a moment to clean them up and make them presentable,
so here they are. Interested?To test, apply the patch and run perl src/tools/msvc/mkvcbuild.pl .
$ perl src/tools/msvc/mkvcbuild.pl .
Warning: no config.pl found, using default.
Unable to determine Visual Studio version: The nmake command wasn't
found. at /home/ioltas/git/postgres/src/tools/msvc/Mkvcbuild.pm line 92.
Is that the expected result?No, I had apparently created by own fake "nmake" shell script some time ago
to work around that. Here is a new patch with that taken care of, too.
With v2 I'm able to successfully run mkvcbuild.pl on linux and macos. I don't
have any knowledge on compiling with windows, so I can't really judge what it's
been doing.
Julien Rouhaud <rjuju123@gmail.com> writes:
On Thu, Feb 13, 2020 at 02:24:43PM +0100, Peter Eisentraut wrote:
When making build system changes that risk breaking the MSVC build system,
it's useful to be able to run the part of the MSVC build tools that read the
makefiles and produce the project files under a not-Windows platform.
With v2 I'm able to successfully run mkvcbuild.pl on linux and macos. I don't
have any knowledge on compiling with windows, so I can't really judge what it's
been doing.
Yeah, I'm wondering exactly how this helps. IME the typical sort of
breakage is "the MSVC build doesn't know that file X needs to be
included when building Y". It seems like just building the project
files will teach one nothing about that type of omission.
I don't have any particular objection to the patch as given, it
just doesn't sound helpful for me.
regards, tom lane
On 2020-02-13 16:36, Tom Lane wrote:
Julien Rouhaud <rjuju123@gmail.com> writes:
On Thu, Feb 13, 2020 at 02:24:43PM +0100, Peter Eisentraut wrote:
When making build system changes that risk breaking the MSVC build system,
it's useful to be able to run the part of the MSVC build tools that read the
makefiles and produce the project files under a not-Windows platform.With v2 I'm able to successfully run mkvcbuild.pl on linux and macos. I don't
have any knowledge on compiling with windows, so I can't really judge what it's
been doing.Yeah, I'm wondering exactly how this helps. IME the typical sort of
breakage is "the MSVC build doesn't know that file X needs to be
included when building Y". It seems like just building the project
files will teach one nothing about that type of omission.
The main benefit is that if you make "blind" edits in the Perl files,
you can verify them easily, first by seeing that the Perl code runs,
second, depending on the circumstances, by diffing the created project
files. Another is that if you do some nontrivial surgery in makefiles,
you can check whether the Perl code can still process them. So the
benefit is mainly that you can iterate faster when working on build
system related things. You still need to do a full test on Windows at
the conclusion, but then hopefully with a better chance of success.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 2020-02-13 16:36, Tom Lane wrote:
Yeah, I'm wondering exactly how this helps. IME the typical sort of
breakage is "the MSVC build doesn't know that file X needs to be
included when building Y". It seems like just building the project
files will teach one nothing about that type of omission.
The main benefit is that if you make "blind" edits in the Perl files,
you can verify them easily, first by seeing that the Perl code runs,
second, depending on the circumstances, by diffing the created project
files. Another is that if you do some nontrivial surgery in makefiles,
you can check whether the Perl code can still process them. So the
benefit is mainly that you can iterate faster when working on build
system related things. You still need to do a full test on Windows at
the conclusion, but then hopefully with a better chance of success.
I see. No objection then.
regards, tom lane
On Thu, Feb 20, 2020 at 09:31:32AM -0500, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
The main benefit is that if you make "blind" edits in the Perl files,
you can verify them easily, first by seeing that the Perl code runs,
second, depending on the circumstances, by diffing the created project
files. Another is that if you do some nontrivial surgery in makefiles,
you can check whether the Perl code can still process them. So the
benefit is mainly that you can iterate faster when working on build
system related things. You still need to do a full test on Windows at
the conclusion, but then hopefully with a better chance of success.I see. No objection then.
None from here either, and the patch is working correctly.
--
Michael
On 2020-02-21 05:00, Michael Paquier wrote:
On Thu, Feb 20, 2020 at 09:31:32AM -0500, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
The main benefit is that if you make "blind" edits in the Perl files,
you can verify them easily, first by seeing that the Perl code runs,
second, depending on the circumstances, by diffing the created project
files. Another is that if you do some nontrivial surgery in makefiles,
you can check whether the Perl code can still process them. So the
benefit is mainly that you can iterate faster when working on build
system related things. You still need to do a full test on Windows at
the conclusion, but then hopefully with a better chance of success.I see. No objection then.
None from here either, and the patch is working correctly.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
committed
crake says that this doesn't pass perlcritic.
regards, tom lane
On 2020-02-21 21:25, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
committed
crake says that this doesn't pass perlcritic.
OK, fixed.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services