Movatterモバイル変換

18.1.1. Requirements

18.1.2. Special Considerations for 64-Bit Windows

18.1.3. Building

18.1.4. Cleaning and Installing

18.1.5. Running the Regression Tests

The following additional products are required to buildPostgreSQL. Use theconfig.pl file to specify which directories the libraries are available in.

The following additional products are not required to get started, but are required to build the complete package. Use theconfig.pl file to specify which directories the libraries are available in.

PostgreSQL will only build for the x64 architecture on 64-bit Windows.

Mixing 32- and 64-bit versions in the same build tree is not supported. The build system will automatically detect if it's running in a 32- or 64-bit environment, and build PostgreSQL accordingly. For this reason, it is important to start the correct command prompt before building.

To use a server-side third party library such asPython orOpenSSL, this librarymust also be 64-bit. There is no support for loading a 32-bit library in a 64-bit server. Several of the third party libraries that PostgreSQL supports may only be available in 32-bit versions, in which case they cannot be used with 64-bit PostgreSQL.

To build all of PostgreSQL in release configuration (the default), run the command:

build

To build all of PostgreSQL in debug configuration, run the command:

build DEBUG

To build just a single project, for example psql, run the commands:

build psqlbuild DEBUG psql

To change the default build configuration to debug, put the following in thebuildenv.pl file:

$ENV{CONFIG}="Debug";

It is also possible to build from inside the Visual Studio GUI. In this case, you need to run:

perl mkvcbuild.pl

from the command prompt, and then open the generatedpgsql.sln (in the root directory of the source tree) in Visual Studio.

Most of the time, the automatic dependency tracking in Visual Studio will handle changed files. But if there have been large changes, you may need to clean the installation. To do this, simply run theclean.bat command, which will automatically clean out all generated files. You can also run it with thedist parameter, in which case it will behave likemake distclean and remove the flex/bison output files as well.

By default, all files are written into a subdirectory of thedebug orrelease directories. To install these files using the standard layout, and also generate the files required to initialize and use the database, run the command:

install c:\destination\directory

If you want to install only the client applications and interface libraries, then you can use these commands:

install c:\destination\directory client

To run the regression tests, make sure you have completed the build of all required parts first. Also, make sure that the DLLs required to load all parts of the system (such as the Perl and Python DLLs for the procedural languages) are present in the system path. If they are not, set it through thebuildenv.pl file. To run the tests, run one of the following commands from thesrc\tools\msvc directory:

vcregress checkvcregress installcheckvcregress plcheckvcregress contribcheckvcregress modulescheckvcregress ecpgcheckvcregress isolationcheckvcregress bincheckvcregress recoverycheckvcregress taptest

To change the schedule used (default is parallel), append it to the command line like:

vcregress check serial

vcregress taptest can be used to run the TAP tests of a target directory, like:

vcregress taptest src\bin\initdb\

For more information about the regression tests, seeChapter 33.

Running the regression tests on client programs withvcregress bincheck, on recovery tests withvcregress recoverycheck, or TAP tests specified withvcregress taptest requires an additional Perl module to be installed:

The TAP tests run withvcregress support the environment variablesPROVE_TESTS, that is expanded automatically using the name patterns given, andPROVE_FLAGS. These can be set on a Windows terminal, before runningvcregress:

set PROVE_FLAGS=--timer --jobs 2set PROVE_TESTS=t/020*.pl t/010*.pl

It is also possible to set up those parameters inbuildenv.pl:

$ENV{PROVE_FLAGS}='--timer --jobs 2'$ENV{PROVE_TESTS}='t/020*.pl t/010*.pl'

Additionally, the behavior of TAP tests can be controlled by a set of environment variables, seeSection 33.4.1.

Some of the TAP tests depend on a set of external commands that would optionally trigger tests related to them. Each one of those variables can be set or unset inbuildenv.pl: