fi

# Error out if the compiler does not support C99, as the codebase

# relies on that.

if test "$ac_cv_prog_cc_c99" = no; then

as_fn_error $? "C compiler \"$CC\" does not support C99" "$LINENO" 5

fi

ac_ext=cpp

ac_cpp='$CXXCPP $CPPFLAGS'

ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'

# -Wdeclaration-after-statement isn't applicable for C++

# Really don't want VLAs to be used in our dialect of C

{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -Werror=vla, for CFLAGS" >&5

$as_echo_n "checking whether ${CC} supports -Werror=vla, for CFLAGS... " >&6; }

if ${pgac_cv_prog_CC_cflags__Werror_vla+:} false; then :

$as_echo_n "(cached) " >&6

else

pgac_save_CFLAGS=$CFLAGS

pgac_save_CC=$CC

CC=${CC}

CFLAGS="${CFLAGS} -Werror=vla"

ac_save_c_werror_flag=$ac_c_werror_flag

ac_c_werror_flag=yes

cat confdefs.h - <<_ACEOF >conftest.$ac_ext

/* end confdefs.h. */

int

main ()

{

;

return 0;

}

_ACEOF

if ac_fn_c_try_compile "$LINENO"; then :

pgac_cv_prog_CC_cflags__Werror_vla=yes

else

pgac_cv_prog_CC_cflags__Werror_vla=no

fi

rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext

ac_c_werror_flag=$ac_save_c_werror_flag

CFLAGS="$pgac_save_CFLAGS"

CC="$pgac_save_CC"

fi

{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CC_cflags__Werror_vla" >&5

$as_echo "$pgac_cv_prog_CC_cflags__Werror_vla" >&6; }

if test x"$pgac_cv_prog_CC_cflags__Werror_vla" = x"yes"; then

CFLAGS="${CFLAGS} -Werror=vla"

fi

# -Wvla is not applicable for C++

{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -Wendif-labels, for CFLAGS" >&5

$as_echo_n "checking whether ${CC} supports -Wendif-labels, for CFLAGS... " >&6; }

AC_PROG_CC([$pgac_cc_list])

AC_PROG_CC_C99()

# Error out if the compiler does not support C99, as the codebase

# relies on that.

if test "$ac_cv_prog_cc_c99" = no; then

AC_MSG_ERROR([C compiler "$CC" does not support C99])

fi

AC_PROG_CXX([$pgac_cxx_list])

# Check if it's Intel's compiler, which (usually) pretends to be gcc,

# These work in some but not all gcc versions

PGAC_PROG_CC_CFLAGS_OPT([-Wdeclaration-after-statement])

# -Wdeclaration-after-statement isn't applicable for C++

# Really don't want VLAs to be used in our dialect of C

PGAC_PROG_CC_CFLAGS_OPT([-Werror=vla])

# -Wvla is not applicable for C++

PGAC_PROG_CC_CFLAGS_OPT([-Wendif-labels])

PGAC_PROG_CXX_CFLAGS_OPT([-Wendif-labels])

PGAC_PROG_CC_CFLAGS_OPT([-Wmissing-format-attribute])

Microsoft tools is to install <productname>Visual Studio Express 2017

for Windows Desktop</productname> and use the included

compiler. It is also possible to build with the full

<productname>Microsoft Visual C++2005 to 2017</productname>.

<productname>Microsoft Visual C++2013 to 2017</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 Studio2005</productname> to

<productname>Visual Studio2013</productname> to

<productname>Visual Studio 2017</productname> (including Express editions),

as well as standalone Windows SDK releases 6.0 to 8.1.

64-bit PostgreSQL builds are supported with

<productname>Microsoft Windows SDK</productname> version 6.0a to 8.1 or

<productname>Visual Studio 2008</productname> and above. Compilation

is supported down to <productname>Windows XP</productname> and

<productname>Windows Server 2003</productname> when building with

<productname>Visual Studio 2005</productname> to

<productname>Visual Studio 2013</productname>. Building with

<productname>Visual Studio 2015</productname> is supported down to

<productname>Windows Vista</productname> and <productname>Windows Server 2008</productname>.

Building with <productname>Visual Studio 2017</productname> is supported

down to <productname>Windows 7 SP1</productname> and <productname>Windows Server 2008 R2 SP1</productname>.

<productname>Visual Studio 2013</productname> and above. Compilation

is supported down to <productname>Windows 7</productname> and

<productname>Windows Server 2008 R2 SP1</productname> when building with

<productname>Visual Studio 2013</productname> to

<productname>Visual Studio 2017</productname>.

<!--

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:

https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2017-system-requirements-vs

-->

</para>

<para>

<listitem>

<para>

You need an <acronym>ISO</acronym>/<acronym>ANSI</acronym> C compiler (at least

C89-compliant). Recent

C99-compliant). Recent

versions of <productname>GCC</productname> are recommended, but

<productname>PostgreSQL</productname> is known to build using a wide variety

of compilers from different vendors.

<title>C Standard</title>

<para>

Code in <productname>PostgreSQL</productname> should only rely on language

features available in the C89 standard. That means a conforming

C89 compiler has to be able to compile postgres, at least aside

from a few platform dependent pieces. Features from later

revision of the C standard or compiler specific features can be

used, if a fallback is provided.

</para>

<para>

For example <literal>static inline</literal> and

<literal>_StaticAssert()</literal> are currently used, even

though they are from newer revisions of the C standard. If not

available we respectively fall back to defining the functions

without inline, and to using a C89 compatible replacement that

performs the same checks, but emits rather cryptic messages.

features available in the C99 standard. That means a conforming

C99 compiler has to be able to compile postgres, at least aside

from a few platform dependent pieces.

</para>

<para>

A few features included in the C99 standard are, at this time, not be

permitted to be used in core <productname>PostgreSQL</productname>

code. This currently includes variable length arrays, intermingled

declarations and code, <literal>//</literal> comments, universal

character names. Reasons for that include portability and historical

practices.

</para>

<para>

Features from later revision of the C standard or compiler specific

features can be used, if a fallback is provided.

</para>

<para>

For example <literal>_StaticAssert()</literal> and

<literal>__builtin_constant_p</literal> are currently used, even though

they are from newer revisions of the C standard and a

<productname>GCC</productname> extension respectively. If not available

we respectively fall back to using a C99 compatible replacement that

performs the same checks, but emits rather cryptic messages and do not

use <literal>__builtin_constant_p</literal>.

</para>

</simplesect>

packageMSBuildProject;

return;

return;

}

packageVC2010Project;

use strict;

use warnings;

use baseqw(MSBuildProject);

no warningsqw(redefine);## no critic

{

my$classname =shift;

my$self =$classname->SUPER::_new(@_);

bless($self,$classname);

$self->{vcver} ='10.00';

return$self;

}

packageVC2012Project;

use strict;

use warnings;

use baseqw(MSBuildProject);

no warningsqw(redefine);## no critic

{

my$classname =shift;

my$self =$classname->SUPER::_new(@_);

bless($self,$classname);

$self->{vcver} ='11.00';

$self->{PlatformToolset} ='v110';

return$self;

}

{

my ($self,$f,$cfgname,$p) =@_;

my$cfgtype =

($self->{type}eq"exe")

?'Application'

: ($self->{type}eq"dll" ?'DynamicLibrary' :'StaticLibrary');

print$f<<EOF;

return;

}

packageVC2013Project;

use strict;

use warnings;

use baseqw(VC2012Project);

use baseqw(MSBuildProject);

no warningsqw(redefine);## no critic

use strict;

use warnings;

use baseqw(VC2012Project);

use baseqw(MSBuildProject);

no warningsqw(redefine);## no critic

use strict;

use warnings;

use baseqw(VC2012Project);

use baseqw(MSBuildProject);

no warningsqw(redefine);## no critic

==========

This directory contains the tools required to build PostgreSQL using

Microsoft Visual Studio2005 - 2017. This builds the whole backend, not just

Microsoft Visual Studio2013 - 2017. 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 Studio2010 or greater)

project files (Visual Studio2013 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

Solution.pm module containing the code to generate the Visual

Studio solution files.

VCBuildProject.pm module containing the code to generate VCBuild based

project files (Visual Studio 2005/2008)

VSObjectFactory.pm factory module providing the code to create the

appropriate project/solution files for the current

environment

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 a VS2005Solution,

a VS2008Solution, a VS2010Solution or a VS2012Solution or a VS2013Solution,

implementing the Solution interface (this could be either a VS2013Solution,

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 (VC2005Project or VC2008Project from VCBuildProject.pm or

VC2010Project or VC2012Project or VC2013Project or VC2015Project or VC2017Project

from MSBuildProject.pm) to it.

Project interface (VC2013Project or VC2015Project or VC2017Project from

MSBuildProject.pm) to it.

When Solution::Save is called, the implementations of Solution and Project

save their content in the appropriate format.

The final step of starting the appropriate build program (msbuild or vcbuild)

isperformed in build.pl again.

The final step of starting the appropriate build program (msbuild) is

performed in build.pl again.