Re: MSVC Build support with visual studio 2019 - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: MSVC Build support with visual studio 2019
Date
Msg-id 20190627072725.GB3509@paquier.xyz
Whole thread Raw
In response to Re: MSVC Build support with visual studio 2019  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Responses Re: MSVC Build support with visual studio 2019
List pgsql-hackers
On Wed, Jun 26, 2019 at 10:29:05PM +1000, Haribabu Kommi wrote:
> Thanks for the review. Yes, that patch applies till 9.5, it is my mistake
> in naming the patch.

I have been able to finally set up an environment with VS 2019 (as
usual this stuff needs time, anyway..), and I can confirm that the
patch is able to compile properly.

-  <productname>Visual Studio 2017</productname> (including Express editions),
-  as well as standalone Windows SDK releases 6.0 to 8.1.
+  <productname>Visual Studio 2019</productname> (including Express editions),
+  as well as standalone Windows SDK releases 8.1a to 10.
I would like to understand why this range of requirements is updated.
Is there any reason to do so.  If we change these docs, what does it
mean in terms of versions of Visual Studio supported?

-or a VS2015Solution or a VS2017Solution, all in Solution.pm, depending on
-the user's build environment) and adding objects implementing the corresponding
-Project interface (VC2013Project or VC2015Project or VC2017Project from
-MSBuildProject.pm) to it.
+or a VS2015Solution or a VS2017Solution or a VS2019Solution, all in Solution.pm,
+depending on the user's build environment) and adding objects implementing
+the corresponding Project interface (VC2013Project or VC2015Project or VC2017Project
+or VC2019Project from MSBuildProject.pm) to it.
This formulation is weird the more we accumulate new objects, let's
put that in a proper list of elements separated with commas except
for the two last ones which should use "or".

s/greather/greater/.

The patch still has typos, and the format is not satisfying yet, so I
have done a set of fixes as per the attached.

-   elsif ($major < 6)
+   elsif ($major < 12)
    {
        croak
-         "Unable to determine Visual Studio version:
            Visual Studio versions before 6.0 aren't supported.";
+         "Unable to determine Visual Studio version:
        Visual Studio versions before 12.0 aren't supported.";
Well, this is a separate bug fix, still I don't mind fixing that in
the same patch as we meddle with those code paths now.  Good catch.

-       croak $visualStudioVersion;
+       carp $visualStudioVersion;
Same here.  Just wouldn't it be better to print the version found in
the same message?

+   # The major visual studio that is supported has nmake version >=
 14.20 and < 15.
    if ($major > 14)
Comment line is too long.  It seems to me that the condition here
should be ($major >= 14 && $minor >= 30).  That's not completely
correct either as we have a version higher than 14.20 for VS 2019 but
that's better than just using 14.29 or a fake number I guess.

So for now I have the attached which applies to HEAD.  The patch is
not indented yet because the conditions in CreateProject() and
CreateSolution() get messed up, but I'll figure out something.

Any comments?  I am wondering the update related to the version range
of the standalone SDKs though.  No need for backpatched versions yet,
first let's agree about the shape of what we want on HEAD.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andrey Lepikhov
Date:
Subject: Re: Removing unneeded self joins
Next
From: Surafel Temesgen
Date:
Subject: Re: FETCH FIRST clause PERCENT option