Remove support for Visual Studio 2013
No members of the buildfarm are using this version of Visual Studio,
resulting in all the code cleaned up here as being mostly dead, and
VS2017 is the oldest version still supported.
More versions could be cut, but the gain would be minimal, while
removing only VS2013 has the advantage to remove from the core code all
the dependencies on the value defined by _MSC_VER, where compatibility
tweaks have accumulated across the years mostly around locales and
strtof(), so that's a nice isolated cleanup.
Note that this commit additionally allows a revert of 3154e16. The
versions of Visual Studio now supported range from 2015 to 2022.
Author: Michael Paquier
Reviewed-by: Juan José Santamaría Flecha, Tom Lane, Thomas Munro, Justin
Pryzby
Discussion: https://postgr.es/m/YoH2IMtxcS3ncWn+@paquier.xyz
This commit is contained in:
Michael Paquier
parent
4ca9985957
commit
6203583b72
|
|
@ -16809,10 +16809,9 @@ fi
|
|||
|
||||
if test "$PORTNAME" = "win32" -o "$PORTNAME" = "cygwin"; then
|
||||
# Cygwin and (apparently, based on test results) Mingw both
|
||||
# have a broken strtof(), so substitute the same replacement
|
||||
# code we use with VS2013. That's not a perfect fix, since
|
||||
# (unlike with VS2013) it doesn't avoid double-rounding, but
|
||||
# we have no better options. To get that, though, we have to
|
||||
# have a broken strtof(), so substitute its implementation.
|
||||
# That's not a perfect fix, since it doesn't avoid double-rounding,
|
||||
# but we have no better options. To get that, though, we have to
|
||||
# force the file to be compiled despite HAVE_STRTOF.
|
||||
case " $LIBOBJS " in
|
||||
*" strtof.$ac_objext "* ) ;;
|
||||
|
|
|
|||
|
|
@ -1919,10 +1919,9 @@ fi
|
|||
|
||||
if test "$PORTNAME" = "win32" -o "$PORTNAME" = "cygwin"; then
|
||||
# Cygwin and (apparently, based on test results) Mingw both
|
||||
# have a broken strtof(), so substitute the same replacement
|
||||
# code we use with VS2013. That's not a perfect fix, since
|
||||
# (unlike with VS2013) it doesn't avoid double-rounding, but
|
||||
# we have no better options. To get that, though, we have to
|
||||
# have a broken strtof(), so substitute its implementation.
|
||||
# That's not a perfect fix, since it doesn't avoid double-rounding,
|
||||
# but we have no better options. To get that, though, we have to
|
||||
# force the file to be compiled despite HAVE_STRTOF.
|
||||
AC_LIBOBJ([strtof])
|
||||
AC_MSG_NOTICE([On $host_os we will use our strtof wrapper.])
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@
|
|||
<productname>Windows</productname>. The simplest way to build with
|
||||
Microsoft tools is to install <productname>Visual Studio 2022</productname>
|
||||
and use the included compiler. It is also possible to build with the full
|
||||
<productname>Microsoft Visual C++ 2013 to 2022</productname>.
|
||||
<productname>Microsoft Visual C++ 2015 to 2022</productname>.
|
||||
In some cases that requires the installation of the
|
||||
<productname>Windows SDK</productname> in addition to the compiler.
|
||||
</para>
|
||||
|
|
@ -77,15 +77,13 @@
|
|||
<para>
|
||||
Both 32-bit and 64-bit builds are possible with the Microsoft Compiler suite.
|
||||
32-bit PostgreSQL builds are possible with
|
||||
<productname>Visual Studio 2013</productname> to
|
||||
<productname>Visual Studio 2015</productname> to
|
||||
<productname>Visual Studio 2022</productname>,
|
||||
as well as standalone Windows SDK releases 8.1a to 10.
|
||||
64-bit PostgreSQL builds are supported with
|
||||
<productname>Microsoft Windows SDK</productname> version 8.1a to 10 or
|
||||
<productname>Visual Studio 2013</productname> and above.
|
||||
<productname>Visual Studio 2015</productname> and above.
|
||||
<!--
|
||||
For 2013 requirements:
|
||||
https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs
|
||||
For 2015 requirements:
|
||||
https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2015-sysrequirements-vs
|
||||
For 2017 requirements:
|
||||
|
|
|
|||
|
|
@ -30,11 +30,6 @@
|
|||
#include <sys/param.h>
|
||||
#endif
|
||||
|
||||
#if defined(_M_AMD64) && _MSC_VER == 1800
|
||||
#include <math.h>
|
||||
#include <versionhelpers.h>
|
||||
#endif
|
||||
|
||||
#include "bootstrap/bootstrap.h"
|
||||
#include "common/username.h"
|
||||
#include "port/atomics.h"
|
||||
|
|
|
|||
|
|
@ -5445,10 +5445,8 @@ calc_joinrel_size_estimate(PlannerInfo *root,
|
|||
double outer_rows,
|
||||
double inner_rows,
|
||||
SpecialJoinInfo *sjinfo,
|
||||
List *restrictlist_in)
|
||||
List *restrictlist)
|
||||
{
|
||||
/* This apparently-useless variable dodges a compiler bug in VS2013: */
|
||||
List *restrictlist = restrictlist_in;
|
||||
JoinType jointype = sjinfo->jointype;
|
||||
Selectivity fkselec;
|
||||
Selectivity jselec;
|
||||
|
|
|
|||
|
|
@ -249,13 +249,9 @@ float4in(PG_FUNCTION_ARGS)
|
|||
* precision). We'd prefer not to throw error for that, so try to
|
||||
* detect whether it's a "real" out-of-range condition by checking
|
||||
* to see if the result is zero or huge.
|
||||
*
|
||||
* Use isinf() rather than HUGE_VALF on VS2013 because it
|
||||
* generates a spurious overflow warning for -HUGE_VALF. Also use
|
||||
* isinf() if HUGE_VALF is missing.
|
||||
*/
|
||||
if (val == 0.0 ||
|
||||
#if !defined(HUGE_VALF) || (defined(_MSC_VER) && (_MSC_VER < 1900))
|
||||
#if !defined(HUGE_VALF)
|
||||
isinf(val)
|
||||
#else
|
||||
(val >= HUGE_VALF || val <= -HUGE_VALF)
|
||||
|
|
|
|||
|
|
@ -950,7 +950,6 @@ cache_locale_time(void)
|
|||
* [2] https://docs.microsoft.com/en-us/windows/win32/intl/locale-names
|
||||
*/
|
||||
|
||||
#if _MSC_VER >= 1900
|
||||
/*
|
||||
* Callback function for EnumSystemLocalesEx() in get_iso_localename().
|
||||
*
|
||||
|
|
@ -1100,7 +1099,6 @@ get_iso_localename(const char *winlocname)
|
|||
|
||||
return NULL;
|
||||
}
|
||||
#endif /* _MSC_VER >= 1900 */
|
||||
|
||||
static char *
|
||||
IsoLocaleName(const char *winlocname)
|
||||
|
|
@ -1115,46 +1113,8 @@ IsoLocaleName(const char *winlocname)
|
|||
return iso_lc_messages;
|
||||
}
|
||||
else
|
||||
{
|
||||
#if (_MSC_VER >= 1900) /* Visual Studio 2015 or later */
|
||||
return get_iso_localename(winlocname);
|
||||
#else
|
||||
_locale_t loct;
|
||||
|
||||
loct = _create_locale(LC_CTYPE, winlocname);
|
||||
if (loct != NULL)
|
||||
{
|
||||
size_t rc;
|
||||
char *hyphen;
|
||||
|
||||
/* Locale names use only ASCII, any conversion locale suffices. */
|
||||
rc = wchar2char(iso_lc_messages, loct->locinfo->locale_name[LC_CTYPE],
|
||||
sizeof(iso_lc_messages), NULL);
|
||||
_free_locale(loct);
|
||||
if (rc == -1 || rc == sizeof(iso_lc_messages))
|
||||
return NULL;
|
||||
|
||||
/*
|
||||
* Since the message catalogs sit on a case-insensitive
|
||||
* filesystem, we need not standardize letter case here. So long
|
||||
* as we do not ship message catalogs for which it would matter,
|
||||
* we also need not translate the script/variant portion, e.g.
|
||||
* uz-Cyrl-UZ to uz_UZ@cyrillic. Simply replace the hyphen with
|
||||
* an underscore.
|
||||
*
|
||||
* Note that the locale name can be less-specific than the value
|
||||
* we would derive under earlier Visual Studio releases. For
|
||||
* example, French_France.1252 yields just "fr". This does not
|
||||
* affect any of the country-specific message catalogs available
|
||||
* as of this writing (pt_BR, zh_CN, zh_TW).
|
||||
*/
|
||||
hyphen = strchr(iso_lc_messages, '-');
|
||||
if (hyphen)
|
||||
*hyphen = '_';
|
||||
return iso_lc_messages;
|
||||
}
|
||||
#endif /* Visual Studio 2015 or later */
|
||||
}
|
||||
#endif /* defined(_MSC_VER) */
|
||||
return NULL; /* Not supported on this version of msvc/mingw */
|
||||
}
|
||||
|
|
|
|||
|
|
@ -531,13 +531,8 @@ typedef unsigned short mode_t;
|
|||
|
||||
#endif /* _MSC_VER */
|
||||
|
||||
#if (defined(_MSC_VER) && (_MSC_VER < 1900)) || \
|
||||
defined(__MINGW32__) || defined(__MINGW64__)
|
||||
#if defined(__MINGW32__) || defined(__MINGW64__)
|
||||
/*
|
||||
* VS2013 has a strtof() that seems to give correct answers for valid input,
|
||||
* even on the rounding edge cases, but which doesn't handle out-of-range
|
||||
* input correctly. Work around that.
|
||||
*
|
||||
* Mingw claims to have a strtof, and my reading of its source code suggests
|
||||
* that it ought to work (and not need this hack), but the regression test
|
||||
* results disagree with me; whether this is a version issue or not is not
|
||||
|
|
|
|||
|
|
@ -191,19 +191,10 @@ static const struct encoding_match encoding_match_list[] = {
|
|||
/*
|
||||
* On Windows, use CP<code page number> instead of the nl_langinfo() result
|
||||
*
|
||||
* Visual Studio 2012 expanded the set of valid LC_CTYPE values, so have its
|
||||
* locale machinery determine the code page. See comments at IsoLocaleName().
|
||||
* For other compilers, follow the locale's predictable format.
|
||||
*
|
||||
* Visual Studio 2015 should still be able to do the same, but the declaration
|
||||
* of lc_codepage is missing in _locale_t, causing this code compilation to
|
||||
* fail, hence this falls back instead on GetLocaleInfoEx. VS 2015 may be an
|
||||
* exception and post-VS2015 versions should be able to handle properly the
|
||||
* codepage number using _create_locale(). So, instead of the same logic as
|
||||
* VS 2012 and VS 2013, this routine uses GetLocaleInfoEx to parse short
|
||||
* locale names like "de-DE", "fr-FR", etc. If those cannot be parsed correctly
|
||||
* process falls back to the pre-VS-2010 manual parsing done with
|
||||
* using <Language>_<Country>.<CodePage> as a base.
|
||||
* This routine uses GetLocaleInfoEx() to parse short locale names like
|
||||
* "de-DE", "fr-FR", etc. If those cannot be parsed correctly process falls
|
||||
* back to the pre-VS-2010 manual parsing done with using
|
||||
* <Language>_<Country>.<CodePage> as a base.
|
||||
*
|
||||
* Returns a malloc()'d string for the caller to free.
|
||||
*/
|
||||
|
|
@ -211,22 +202,9 @@ static char *
|
|||
win32_langinfo(const char *ctype)
|
||||
{
|
||||
char *r = NULL;
|
||||
|
||||
#if defined(_MSC_VER) && (_MSC_VER < 1900)
|
||||
_locale_t loct = NULL;
|
||||
|
||||
loct = _create_locale(LC_CTYPE, ctype);
|
||||
if (loct != NULL)
|
||||
{
|
||||
r = malloc(16); /* excess */
|
||||
if (r != NULL)
|
||||
sprintf(r, "CP%u", loct->locinfo->lc_codepage);
|
||||
_free_locale(loct);
|
||||
}
|
||||
#else
|
||||
char *codepage;
|
||||
|
||||
#if defined(_MSC_VER) && (_MSC_VER >= 1900)
|
||||
#if defined(_MSC_VER)
|
||||
uint32 cp;
|
||||
WCHAR wctype[LOCALE_NAME_MAX_LENGTH];
|
||||
|
||||
|
|
@ -279,7 +257,6 @@ win32_langinfo(const char *ctype)
|
|||
}
|
||||
}
|
||||
}
|
||||
#endif
|
||||
|
||||
return r;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -54,15 +54,6 @@ strtof(const char *nptr, char **endptr)
|
|||
|
||||
#elif HAVE_BUGGY_STRTOF
|
||||
/*
|
||||
* On Windows, there's a slightly different problem: VS2013 has a strtof()
|
||||
* that returns the correct results for valid input, but may fail to report an
|
||||
* error for underflow or overflow, returning 0 instead. Work around that by
|
||||
* trying strtod() when strtof() returns 0.0 or [+-]Inf, and calling it an
|
||||
* error if the result differs. Also, strtof() doesn't handle subnormal input
|
||||
* well, so prefer to round the strtod() result in such cases. (Normally we'd
|
||||
* just say "too bad" if strtof() doesn't support subnormals, but since we're
|
||||
* already in here fixing stuff, we might as well do the best fix we can.)
|
||||
*
|
||||
* Cygwin has a strtof() which is literally just (float)strtod(), which means
|
||||
* we can't avoid the double-rounding problem; but using this wrapper does get
|
||||
* us proper over/underflow checks. (Also, if they fix their strtof(), the
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
package MSBuildProject;
|
||||
|
||||
#
|
||||
# Package that encapsulates a MSBuild project file (Visual C++ 2013 or greater)
|
||||
# Package that encapsulates a MSBuild project file (Visual C++ 2015 or greater)
|
||||
#
|
||||
# src/tools/msvc/MSBuildProject.pm
|
||||
#
|
||||
|
|
@ -405,31 +405,6 @@ EOF
|
|||
return;
|
||||
}
|
||||
|
||||
package VC2013Project;
|
||||
|
||||
#
|
||||
# Package that encapsulates a Visual C++ 2013 project file
|
||||
#
|
||||
|
||||
use strict;
|
||||
use warnings;
|
||||
use base qw(MSBuildProject);
|
||||
|
||||
no warnings qw(redefine); ## no critic
|
||||
|
||||
sub new
|
||||
{
|
||||
my $classname = shift;
|
||||
my $self = $classname->SUPER::_new(@_);
|
||||
bless($self, $classname);
|
||||
|
||||
$self->{vcver} = '12.00';
|
||||
$self->{PlatformToolset} = 'v120';
|
||||
$self->{ToolsVersion} = '12.0';
|
||||
|
||||
return $self;
|
||||
}
|
||||
|
||||
package VC2015Project;
|
||||
|
||||
#
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ MSVC build
|
|||
==========
|
||||
|
||||
This directory contains the tools required to build PostgreSQL using
|
||||
Microsoft Visual Studio 2013 - 2022. This builds the whole backend, not just
|
||||
Microsoft Visual Studio 2015 - 2022. This builds the whole backend, not just
|
||||
the libpq frontend library. For more information, see the documentation
|
||||
chapter "Installation on Windows" and the description below.
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ Install.pm module containing the install logic
|
|||
Mkvcbuild.pm module containing the code to generate the Visual
|
||||
Studio build (project/solution) files
|
||||
MSBuildProject.pm module containing the code to generate MSBuild based
|
||||
project files (Visual Studio 2013 or greater)
|
||||
project files (Visual Studio 2015 or greater)
|
||||
Project.pm module containing the common code to generate the
|
||||
Visual Studio project files. Also provides the
|
||||
common interface of all project file generators
|
||||
|
|
@ -88,10 +88,10 @@ config_default.pl to create the configuration arguments.
|
|||
These configuration arguments are passed over to Mkvcbuild::mkvcbuild
|
||||
(Mkvcbuild.pm) which creates the Visual Studio project and solution files.
|
||||
It does this by using VSObjectFactory::CreateSolution to create an object
|
||||
implementing the Solution interface (this could be either VS2013Solution,
|
||||
implementing the Solution interface (this could be either
|
||||
VS2015Solution, VS2017Solution, VS2019Solution or VS2022Solution, all in
|
||||
Solution.pm, depending on the user's build environment) and adding objects
|
||||
implementing the corresponding Project interface (VC2013Project,
|
||||
implementing the corresponding Project interface (
|
||||
VC2015Project, VC2017Project, VC2019Project or VC2022Project from
|
||||
MSBuildProject.pm) to it. When Solution::Save is called, the implementations
|
||||
of Solution and Project save their content in the appropriate format.
|
||||
|
|
|
|||
|
|
@ -1263,34 +1263,6 @@ sub GetFakeConfigure
|
|||
return $cfg;
|
||||
}
|
||||
|
||||
package VS2013Solution;
|
||||
|
||||
#
|
||||
# Package that encapsulates a Visual Studio 2013 solution file
|
||||
#
|
||||
|
||||
use Carp;
|
||||
use strict;
|
||||
use warnings;
|
||||
use base qw(Solution);
|
||||
|
||||
no warnings qw(redefine); ## no critic
|
||||
|
||||
sub new
|
||||
{
|
||||
my $classname = shift;
|
||||
my $self = $classname->SUPER::_new(@_);
|
||||
bless($self, $classname);
|
||||
|
||||
$self->{solutionFileVersion} = '12.00';
|
||||
$self->{vcver} = '12.00';
|
||||
$self->{visualStudioName} = 'Visual Studio 2013';
|
||||
$self->{VisualStudioVersion} = '12.0.21005.1';
|
||||
$self->{MinimumVisualStudioVersion} = '10.0.40219.1';
|
||||
|
||||
return $self;
|
||||
}
|
||||
|
||||
package VS2015Solution;
|
||||
|
||||
#
|
||||
|
|
|
|||
|
|
@ -33,11 +33,7 @@ sub CreateSolution
|
|||
$visualStudioVersion = DetermineVisualStudioVersion();
|
||||
}
|
||||
|
||||
if ($visualStudioVersion eq '12.00')
|
||||
{
|
||||
return new VS2013Solution(@_);
|
||||
}
|
||||
elsif ($visualStudioVersion eq '14.00')
|
||||
if ($visualStudioVersion eq '14.00')
|
||||
{
|
||||
return new VS2015Solution(@_);
|
||||
}
|
||||
|
|
@ -87,11 +83,7 @@ sub CreateProject
|
|||
$visualStudioVersion = DetermineVisualStudioVersion();
|
||||
}
|
||||
|
||||
if ($visualStudioVersion eq '12.00')
|
||||
{
|
||||
return new VC2013Project(@_);
|
||||
}
|
||||
elsif ($visualStudioVersion eq '14.00')
|
||||
if ($visualStudioVersion eq '14.00')
|
||||
{
|
||||
return new VC2015Project(@_);
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in New Issue