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 "* ) ;;
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.])
<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>
<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:
#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"
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;
* 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)
* [2] https://docs.microsoft.com/en-us/windows/win32/intl/locale-names
*/
-#if _MSC_VER >= 1900
/*
* Callback function for EnumSystemLocalesEx() in get_iso_localename().
*
return NULL;
}
-#endif /* _MSC_VER >= 1900 */
static char *
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 */
}
#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
/*
* 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.
*/
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];
}
}
}
-#endif
return r;
}
#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
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
#
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;
#
==========
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.
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
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.
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;
#
$visualStudioVersion = DetermineVisualStudioVersion();
}
- if ($visualStudioVersion eq '12.00')
- {
- return new VS2013Solution(@_);
- }
- elsif ($visualStudioVersion eq '14.00')
+ if ($visualStudioVersion eq '14.00')
{
return new VS2015Solution(@_);
}
$visualStudioVersion = DetermineVisualStudioVersion();
}
- if ($visualStudioVersion eq '12.00')
- {
- return new VC2013Project(@_);
- }
- elsif ($visualStudioVersion eq '14.00')
+ if ($visualStudioVersion eq '14.00')
{
return new VC2015Project(@_);
}
projects / postgresql.git / commitdiff