Configuration
La première étape de la procédure d'installation est de configurer
l'arborescence système et de choisir les options intéressantes.
Ce qui est fait en exécutant le script configure
. Pour une
installation par défaut, entrer simplement
./configure
Ce script exécutera de nombreux tests afin de déterminer les valeurs
de certaines variables dépendantes du système et de détecter certains aléas
relatifs au système d'exploitation. Il créera divers
fichiers dans l'arborescence de compilation pour enregistrer ce qui a été
trouvé. configure
peut aussi être exécuté à
partir d'un répertoire hors de l'arborescence des sources pour
conserver l'arborescence de compilation séparé. Cette procédure est aussi
appelé une construction a
VPATH
build. Voici comment la faire :
mkdir build_dir
cd build_dir
/path/to/source/tree/configure [les options vont ici]
make
La configuration par défaut compilera le serveur et les utilitaires, aussi
bien que toutes les applications clientes et interfaces qui requièrent
seulement un compilateur C. Tous les fichiers seront installés par défaut
sous /usr/local/pgsql
.
Les processus de compilation et d'installation peuvent être personnalisés
par l'utilisation d'une ou plusieurs options sur la ligne de commande après
configure
:
--prefix=PREFIX
Installe tous les fichiers dans le répertoire PREFIX
au lieu du répertoire /usr/local/pgsql
.
Les fichiers actuels seront installés dans divers
sous-répertoires ; aucun fichier ne sera directement installé
sous PREFIX
.
Pour satisfaire des besoins spécifiques, les sous-répertoires peuvent
être personnalisés à l'aide des options qui suivent.
Toutefois, en laissant les options par défaut, l'installation est
déplaçable, ce qui signifie que le réperoire peut être déplacé après
installation. (Cela n'affecte pas les emplacements de
man
et doc
.)
Pour les installations déplaçables, on peut utiliser
l'option --disable-rpath
de configure
.
De plus, il faut indiquer au système d'exploitation
comment trouver les bibliothèques partagées.
--exec-prefix=EXEC-PREFIX
Les fichiers qui dépendent de l'architecture peuvent être installés dans
un répertoire différent, EXEC-PREFIX
, de celui donné
par PREFIX
. Ce qui peut être utile pour partager
les fichiers dépendant de l'architecture entre plusieurs machines.
S'il est omis, EXEC-PREFIX
est égal à
PREFIX
et les fichiers dépendant seront installés
sous la même arborescence que les fichiers indépendants de
l'architecture, ce qui est probablement le but recherché.
--bindir=REPERTOIRE
Précise le répertoire des exécutables. Par défaut, il s'agit de
, ce
qui signifie EXEC-PREFIX
/bin/usr/local/pgsql/bin
.
--sysconfdir=REPERTOIRE
Précise le répertoire de divers fichiers de configuration. Par défaut,
il s'agit de
.
PREFIX
/etc
--libdir=REPERTOIRE
Précise le répertoire d'installation des bibliothèques et des
modules chargeables dynamiquement. Par défaut, il s'agit de
.
EXEC-PREFIX
/lib
--includedir=REPERTOIRE
Précise le répertoire d'installation des en-têtes C et C++. Par défaut, il
s'agit de
.
PREFIX
/include
--datarootdir=REPERTOIRE
Indique le répertoire racine de différents types de fichiers de données
en lecture seule. Cela ne sert qu'à paramétrer des valeurs par
défaut pour certaines des options suivantes. La valeur par défaut est
.
PREFIX
/share
--datadir=REPERTOIRE
Indique le répertoire pour les fichiers de données en lecture seule
utilisés par les programmes installés. La valeur par défaut est
.
Cela n'a aucun rapport avec l'endroit où les fichiers de base de données
seront placés.
DATAROOTDIR
--localedir=REPERTOIRE
Indique le répertoire pour installer les données locales, en
particulier les fichiers catalogues de traductions de messages. La
valeur par défaut est
.
DATAROOTDIR
/locale
--mandir=REPERTOIRE
Les pages man fournies avec PostgreSQL seront
installées sous ce répertoire, dans leur sous-répertoire
man
respectif.
Par défaut, il s'agit de x
.
DATAROOTDIR
/man
--docdir=RÉPERTOIRE
Configure le répertoire racine pour installer les fichiers de documentation,
sauf les pages « man ». Ceci ne positionne la valeur par défaut
que pour les options suivantes. La valeur par défaut pour cette option est
.
DATAROOTDIR
/doc/postgresql
--htmldir=RÉPERTOIRE
La documentation formatée en HTML pour PostgreSQL
sera installée dans ce répertoire. La valeur par défaut est
.
DATAROOTDIR
Une attention toute particulière a été prise afin de rendre possible
l'installation de PostgreSQL dans des répertoires
partagés (comme /usr/local/include
) sans
interférer avec des noms de fichiers relatifs au reste du système.
En premier lieu, le mot « /postgresql
»
est automatiquement ajouté aux répertoires datadir
,
sysconfdir
et docdir
,
à moins que le nom du répertoire à partir de la racine ne contienne déjà
le mot « postgres
» ou
« pgsql
». Par exemple, si
/usr/local
est choisi comme préfixe,
la documentation sera installée dans
/usr/local/doc/postgresql
, mais si le
préfixe est /opt/postgres
, alors il sera dans
/opt/postgres/doc
. Les fichiers d'en-tête
publiques C de l'interface cliente seront installés sous
includedir
et sont indépendants des noms de
fichiers relatifs au reste du système. Les fichiers d'en-tête privés et
les fichiers d'en-tête du serveur sont installés dans des répertoires
privés sous includedir
.
Voir la documentation de chaque interface pour savoir comment obtenir
ces fichiers d'en-tête.
Enfin, un répertoire privé sera aussi créé si nécessaire sous
libdir
pour les modules chargeables dynamiquement.
--with-extra-version=STRING
Ajoute STRING
au numéro de version de
PostgreSQL. Cela peut être utilisé, par exmeple, pour marquer des
binaires compilés depuis des instantanés Git ne faisant pas encore
partie d'une version officielle ou contenant des patchs particuliers
avec une chaînes de texte supplémentaire telle qu'un identifiant
git describe
ou un numéro de version d'un paquet
d'une distribution.
--with-includes=REPERTOIRES
REPERTOIRES
est une liste de répertoires séparés par
des caractères deux points (:) qui sera ajoutée à la liste de recherche
des fichiers d'en-tête. Si vous avez des paquetages optionnels (tels
que Readline GNU) installés dans des répertoires non
conventionnels, vous pouvez utiliser cette option et certainement
l'option --with-libraries
correspondante.
Exemple :
--with-includes=/opt/gnu/include:/usr/sup/include
.
--with-libraries=REPERTOIRES
REPERTOIRES
est une liste de recherche de répertoires
de bibliothèques séparés par des caractères deux points (:).
Si des paquets sont installés dans des répertoires non conventionnels,
il peut s'avérer nécessaire d'utiliser cette option (et l'option correspondante
--with-includes
).
Exemple : --with-libraries=/opt/gnu/lib:/usr/sup/lib
.
--enable-nls[=LANGUES
]
Permet de mettre en place le support des langues natives
(NLS). C'est la possibilité d'afficher les messages
des programmes dans une langue autre que l'anglais.
LANGUES
est une liste, optionnelle, des codes
des langues que vous voulez supporter séparés par un espace. Par
exemple, --enable-nls='de fr'
(l'intersection entre la
liste et l'ensemble des langues traduites actuellement sera calculée
automatiquement). En l'absence de liste, toutes les
traductions disponibles seront installées.
Pour utiliser cette option, une implantation de l'API Gettext est nécessaire ; voir ci-dessous.
--with-pgport=NUMERO
Positionne NUMERO
comme numéro de port par défaut
pour le serveur et les clients. La valeur par défaut est 5432. Le port
peut toujours être changé ultérieurement mais, précisé ici,
les exécutables du serveur et des clients auront la même valeur
par défaut, ce qui est vraiment très pratique. Habituellement, la
seule bonne raison de choisir une valeur autre que celle par défaut
est l'exécution de plusieurs serveurs
PostgreSQL sur la même machine.
--with-perl
Permet l'utilisation du langage de procédures PL/Perl côté serveur.
--with-python
Permet la compilation du langage de procédures PL/Python.
--with-tcl
Permet la compilation du langage de procédures PL/Tcl.
--with-tclconfig=REPERTOIRE
Tcl installe les fichiers tclConfig.sh
, contenant
certaines informations de configuration nécessaires pour compiler le
module d'interfaçage avec Tcl. Ce fichier est trouvé automatiquement
mais, si pour utiliser une version différente de Tcl, il faut indiquer le répertoire où
le trouver.
--with-gssapi
Construire avec le support de l'authentification GSSAPI. Sur de
nombreux systèmes, GSSAPI (qui fait habituellement partie d'une
installation Kerberos) n'est pas installé dans un emplacement
recherché par défaut (c'est-à-dire /usr/include
,
/usr/lib
), donc vous devez utiliser les options
--with-includes
et --with-libraries
en plus de cette option. configure
vérifiera les
fichiers d'en-têtes nécessaires et les bibliothèques pour s'assurer
que votre installation GSSAPI est suffisante avant de continuer.
--with-krb-srvnam=NOM
Le nom par défaut du service principal de Kerberos utilisé.
postgres
est pris par défaut. Il n'y a
habituellement pas de raison de le changer sauf dans le cas d'un
environnement Windows, auquel cas il doit être mis en majuscule,
POSTGRES
.
--with-icu
Installer PostgreSQL avec la bibliothèque ICU L'installation des paquets ICU4C et pkg-config sont un pré-requis. La version minimale requise de ICU4C est actuellement la 4.2.
Par défaut,
pkg-config
sera utilisé pour trouver les options requises de compilation. C'est
supporté par les versions 4.6 et ultérieures de
ICU4C. Pour les versions plus anciennes ou
si pkg-config n'est pas disponible, les
variables ICU_CFLAGS
et ICU_LIBS
peuvent
être données à configure
, comme dans cet
exemple :
./configure ... --with-icu ICU_CFLAGS='-I/some/where/include' ICU_LIBS='-L/some/where/lib -licui18n -licuuc -licudata'
(Si ICU4C est dans le chemin de recherche
par défaut du compilateur, alors vous aurez besoin d'indiquer une
chaîne non vide pour éviter l'utilisation de pkg-
config, par exemple ICU_CFLAGS=' '
.)
--with-openssl
Compile le support de connexion SSL (chiffrement).
Le paquetage OpenSSL doit être
installé. configure
vérifiera que les fichiers d'en-tête
et les bibliothèques soient installés pour s'assurer que votre
installation d'OpenSSL est suffisante avant de
continuer.
--with-pam
Compile le support PAM (Modules d'Authentification Pluggable).
--with-bsd-auth
Compile le support de l'authentification BSD (l'environnement d'authentification BSD est uniquement disponible sur OpenBSD actuellement.)
--with-ldap
Demande l'ajout du support de LDAP
pour l'authentification et la recherche des paramètres de connexion
(voir Section 33.17 et Section 20.3.7).
Sur Unix, cela requiert l'installation du paquet
OpenLDAP. Sur Windows, la bibliothèque
WinLDAP est utilisée par défaut.
configure
vérifiera l'existence des fichiers d'en-tête
et des bibliothèques requis pour s'assurer que votre installation
d'OpenLDAP est suffisante avant de continuer.
--with-systemd
Compile le support des notifications du service systemd . Ceci améliore l'intégration si le binaire du serveur est lancé par systemd mais n'a pas d'impact dans le cas contraire (voir Section 18.3 pour plus d'informations). libsystemd et les fichiers en-têtes associés doivent être installés pour pouvoir utiliser cette option.
--without-readline
Évite l'utilisation de la bibliothèque Readline (et de celle de libedit). Cela désactive l'édition de la ligne de commande et l'historique dans psql, ce n'est donc pas recommandé.
--with-libedit-preferred
Favorise l'utilisation de la bibliothèque libedit (sous licence BSD) plutôt que Readline (GPL). Cette option a seulement un sens si vous avez installé les deux bibliothèques ; dans ce cas, par défaut, Readline est utilisé.
--with-bonjour
Compile le support de Bonjour. Ceci requiert le support de Bonjour dans votre système d'exploitation. Recommandé sur macOS.
--with-uuid=LIBRARY
Compile le module uuid-ossp (qui fournit les
fonctions pour générer les UUID), en utilisant la bibliothèque UUID
spécifiée.
LIBRARY
doit correspondre à une de ces
valeurs :
bsd
pour utiliser les fonctions UUID trouvées dans
FreeBSD et quelques autres systèmes dérivés de BSD
e2fs
pour utiliser la bibliothèque UUID créée par
le projet e2fsprogs
; cette bibliothèque est
présente sur la plupart des systèmes Linux et sur macOS, et peut
être obtenu sur d'autres plateformes également
ossp
pour utiliser la bibliothèque OSSP UUID
--with-ossp-uuid
Équivalent obsolète de --with-uuid=ossp
.
--with-libxml
Construit avec libxml2, activant ainsi le support de SQL/XML. Une version 2.6.23 ou ultérieure de libxml2 est requise pour cette fonctionnalité.
Pour détecter les options requises pour le compilateur et l'éditeur de
liens, PostgreSQL va demander à pkg-config
, s'il est
installé et s'il connaît libxml2. Sinon, le programme
xml2-config
, qui est installé par libxml2, sera
utilisé s'il est trouvé. L'utilisation de pkg-config
est préférée, parce qu'elle gère mieux les installations
multiarchitectures.
Pour utiliser une installation libxml2 se trouvant dans un emplacement
inhabituel, vous pouvez configurer les variables d'environnement
relatives à pkg-config
(voir sa documentation), ou
configurer la variable d'environnement XML2_CONFIG
pour
qu'elle pointe sur le programme xml2-config
appartenant à l'installation libxml2, ou configurer les variables
XML2_CFLAGS
et XML2_LIBS
. (Si
pkg-config
est installé, alors pour surcharger son
idée de l'emplacement de libxml2 vous devez soit configurer
XML2_CONFIG
soit XML2_CFLAGS
et
XML2_LIBS
avec des chaînes non vides.)
--with-libxslt
Utilise libxslt pour construire le module xml2
xml2. Le
module contrib/xml2
se base sur cette
bibliothèque pour réaliser les transformations XSL du XML.
--disable-float4-byval
Désactive le passage « par valeur » des valeurs float4, entraînant leur passage « par référence » à la place. Cette option a un coût en performance, mais peut être nécessaire pour maintenir la compatibilité avec des anciennes fonctions créées par l'utilisateur qui sont écrites en C et utilisent la convention d'appel « version 0 ». Une meilleure solution à long terme est de mettre à jour toutes ces fonctions pour utiliser la convention d'appel « version 1 ».
--disable-float8-byval
Désactive le passage « par valeur » des valeurs float8,
entraînant leur passage « par référence » à la place.
Cette option a un coût en performance, mais peut être nécessaire pour
maintenir la compatibilité avec des anciennes fonctions créées par
l'utilisateur qui sont écrites en C et utilisent la convention d'appel
« version 0 ». Une meilleure solution à long terme est
de mettre à jour toutes ces fonctions pour utiliser la convention d'appel
« version 1 ».
Notez que cette option n'affecte pas que float8, mais aussi int8 et
quelques types apparentés comme timestamp.
Sur les plateformes 32 bits, --disable-float8-byval
est la valeur par défaut, et il n'est pas permis de sélectionner
--enable-float8-byval
.
--with-segsize=TAILLESEG
Indique la taille d'un segment, en gigaoctets. Les grandes tables sont divisées en plusieurs fichiers du système d'exploitation, chacun de taille égale à la taille de segment. Cela évite les problèmes avec les limites de tailles de fichiers qui existent sur de nombreuses plateformes. Si votre système d'exploitation supporte les fichiers de grande taille (« largefile »), ce qui est le cas de la plupart d'entre eux de nos jours, vous pouvez utiliser une plus grande taille de segment. Cela peut être utile pour réduire le nombre de descripteurs de fichiers qui peuvent être utilisés lors de travail sur des très grandes tables. Attention à ne pas sélectionner une valeur plus grande que ce qui est supporté par votre plateforme et le(s) système(s) de fichiers que vous prévoyez d'utiliser. D'autres outils que vous pourriez vouloir utiliser, tels que tar, pourraient aussi limiter la taille maximum utilisable pour un fichier. Il est recommandé, même si pas vraiment nécessaire, que cette valeur soit un multiple de 2. Notez que changer cette valeur impose de faire un initdb.
--with-blocksize=TAILLEBLOC
Indique la taille d'un bloc, en kilooctets. C'est l'unité de stockage et d'entrée/sortie dans les tables. La valeur par défaut, 8 kilooctets, est appropriée pour la plupart des cas ; mais d'autres valeurs peuvent être utilises dans des cas spéciaux. Cette valeur doit être une puissance de 2 entre 1 et 32 (kilooctets). Notez que changer cette valeur impose de faire un initdb.
--with-wal-segsize=TAILLESEG
Indique la taille d'un segment WAL, en mégaoctets. C'est la taille de chaque fichier individuel dans les journaux de transactions. Il peut être utile d'ajuster cette taille pour contrôler la granularité du transport de journaux de transations. La valeur par défaut est de 16 mégaoctets. La valeur doit être une puissance de 2 entre 1 et 6 (mégaoctets). Notez que changer cette valeur impose de faire un initdb.
--with-wal-blocksize=TAILLEBLOC
Indique la taille d'un bloc WAL, en kilooctets. C'est l'unité de stockage et d'entrée/sortie dans le journal des transactions. La valeur par défaut, 8 kilooctets, est appropriée pour la plupart des cas ; mais d'autres valeurs peuvent être utilises dans des cas spéciaux. La valeur doit être une puissance de 2 entre 1 et 1024 (kilooctets).
--disable-spinlocks
Autorise le succès de la construction y compris lorsque PostgreSQL n'a pas le support spinlock du CPU pour la plateforme. Ce manque de support résultera en des performances faibles ; du coup, cette option devra seulement être utilisée si la construction échoue et vous informe du manque de support de spinlock sur votre plateforme. Si cette option est requise pour construire PostgreSQL sur votre plateforme, merci de rapporter le problème aux développeurs de PostgreSQL.
--disable-strong-random
Autorise le succès de la construction y compris lorsque
PostgreSQL n'a pas le support
pour les nombres aléatoires forts sur la plateforme.
Une source de nombres aléatoires est nécessaire pour certains
protocoles d'authentification, de même que certaines procédures
du module pgcrypto
pgcrypto.
Le paramètre --disable-strong-random
désactive
toutes les fonctionnalités qui nécessitent des nombres aléatoires
forts pour la cryptographie et y substitue un générateur fragile
de nombres pseudo aléatoires pour générer les valeurs pour
l'authentification salée et les clés d'annulation de requêtes.
Cela rend l'authentification moins sécurisée.
--disable-thread-safety
Désactive la sûreté des threads pour les bibliothèques clients. Ceci empêche les threads concurrents dans les programmes libpq et ECPG de contrôler avec sûreté leur pointeurs de connexion privés.
--with-system-tzdata=RÉPERTOIRE
PostgreSQL inclut sa propre base de données
des fuseaux horaires, nécessaire pour les opérations sur les dates et
les heures. Cette base de données est en fait compatible avec la base
de fuseaux horaires IANA fournie par de nombreux
systèmes d'exploitation comme FreeBSD, Linux et Solaris, donc ce serait
redondant de l'installer une nouvelle fois. Quand cette option est
utilisée, la base des fuseaux horaires, fournie par le système, dans
RÉPERTOIRE
est utilisée à la place de celle
inclus dans la distribution des sources de PostgreSQL.
RÉPERTOIRE
doit être indiqué avec un chemin
absolu. /usr/share/zoneinfo
est un répertoire
très probable sur certains systèmes d'exploitation. Notez que la routine
d'installation ne détectera pas les données de fuseau horaire différentes
ou erronées. Si vous utilisez cette option, il vous est conseillé de
lancer les tests de régression pour vérifier que les données de fuseau
horaire que vous pointez fonctionnent correctement avec
PostgreSQL.
Cette option a pour cible les distributeurs de paquets binaires qui connaissent leur système d'exploitation. Le principal avantage d'utiliser cette option est que le package PostgreSQL n'aura pas besoin d'être mis à jour à chaque fois que les règles des fuseaux horaires changent. Un autre avantage est que PostgreSQL peut être cross-compilé plus simplement si les fichiers des fuseaux horaires n'ont pas besoin d'être construit lors de l'installation.
--without-zlib
Évite l'utilisation de la bibliothèque Zlib. Cela désactive le support des archives compressées dans pg_dump et pg_restore. Cette option est seulement là pour les rares systèmes qui ne disposent pas de cette bibliothèque.
--enable-debug
Compile tous les programmes et bibliothèques en mode de débogage. Cela signifie que vous pouvez exécuter les programmes via un débogueur pour analyser les problèmes. Cela grossit considérablement la taille des exécutables et, avec des compilateurs autres que GCC, habituellement, cela désactive les optimisations du compilateur, provoquant des ralentissements. Cependant, mettre ce mode en place est extrêmement utile pour repérer les problèmes. Actuellement, cette option est recommandée pour les installations en production seulement si vous utilisez GCC. Néanmoins, vous devriez l'utiliser si vous développez ou si vous utilisez une version béta.
--enable-coverage
Si vous utilisez GCC, les programmes et bibliothèques sont compilés avec de l'instrumentation de test de couverture de code. Quand ils sont exécutés, ils génèrent des fichiers dans le répertoire de compilation avec des métriques de couverture de code. Voir Section 32.5 pour davantage d'informations. Cette option ne doit être utilisée qu'avec GCC et uniquement en phase de développement.
--enable-profiling
En cas d'utilisation de GCC, tous les programmes et bibliothèques
sont compilés pour qu'elles puissent être profilées. À la sortie du
processus serveur, un sous-répertoire sera créé pour contenir le
fichier gmon.out
à utiliser pour le profilage.
Cette option est à utiliser seulement avec GCC lors d'un développement.
--enable-cassert
Permet la vérification des assertions par le serveur qui teste de nombreux cas de conditions « impossibles ». Ce qui est inestimable dans le cas de développement, mais les tests peuvent ralentir sensiblement le système. Activer cette option n'influe pas sur la stabilité de votre serveur ! Les assertions vérifiées ne sont pas classées par ordre de sévérité et il se peut qu'un bogue anodin fasse redémarrer le serveur s'il y a un échec de vérification. Cette option n'est pas recommandée dans un environnement de production mais vous devriez l'utiliser lors de développement ou pour les versions béta.
--enable-depend
Active la recherche automatique des dépendances. Avec cette option, les fichiers makefile sont appelés pour recompiler les fichiers objet dès qu'un fichier d'en-tête est modifié. C'est pratique si vous faites du développement, mais inutile si vous ne voulez que compiler une fois et installer. Pour le moment, cette option ne fonctionne qu'avec GCC.
--enable-dtrace
Compile PostgreSQL avec le support de l'outil de trace dynamique, DTrace. Voir Section 28.5 pour plus d'informations.
Pour pointer vers le programme dtrace
, la variable
d'environnement DTRACE
doit être configurée. Ceci sera
souvent nécessaire car dtrace
est typiquement
installé sous /usr/sbin
, qui pourrait ne pas être
dans le chemin.
Des options supplémentaires en ligne de commande
peuvent être indiquées dans la variable d'environnement
DTRACEFLAGS
pour le programme dtrace
.
Sur Solaris, pour inclure le support de DTrace dans un exécutable 64-bit, ajoutez
l'option DTRACEFLAGS="-64"
pour configure. Par
exemple, en utilisant le compilateur GCC :
./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
En utilisant le compilateur de Sun :
./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...
--enable-tap-tests
Active les tests utilisant les outils TAP de Perl. Cela nécessite une
installation de Perl et de son module IPC::Run
.
Section 32.4
pour plus d'informations.
Si vous préférez utiliser un compilateur C différent de ceux listés par
configure
, positionnez la variable
d'environnement CC
pour qu'elle pointe sur le compilateur de
votre choix.
Par défaut, configure
pointe sur
gcc
s'il est disponible, sinon il utilise celui par
défaut de la plateforme (habituellement cc
).
De façon similaire, vous pouvez repositionner les options par défaut du
compilateur à l'aide de la variable CFLAGS
.
Les variables d'environnement peuvent être indiquées sur la ligne de
commande configure
, par exemple :
./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
Voici une liste des variables importantes qui sont configurables de cete façon :
BISON
programme Bison
CC
compilateur C
CFLAGS
options à passer au compilateur C
CPP
préprocesseur C
CPPFLAGS
options à passer au préprocesseur C
DTRACE
emplacement du programme dtrace
DTRACEFLAGS
options à passer au programme dtrace
FLEX
programme Flex
LDFLAGS
options à utiliser lors de l'édition des liens des exécutables et des bibliothèques partagées
LDFLAGS_EX
options supplémentaires valables uniquement lors de l'édition des liens des exécutables
LDFLAGS_SL
options supplémentaires valables uniquement lors de l'édition des liens des bibliothèques partagées
MSGFMT
programme msgfmt
pour le support des langues
PERL
programme interpréteur Perl. Il sera utilisé pour déterminer les
dépendances pour la construction de PL/Perl. La valeur par défaut est
perl
.
PYTHON
programme interpréteur Python. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Python. De plus, si Python 2 ou 3 est spécifié ici (ou implicitement choisi), il détermine la variante de PL/Python qui devient disponible. Voir Voir Section 32.4 pour plus d'informations.
Si vous préférez utiliser un compilateur C différent de ceux listés par
configure
, positionnez la variable
d'environnement CC
pour qu'elle pointe sur le compilateur de
votre choix.
Par défaut, configure
pointe sur
gcc
s'il est disponible, sinon il utilise celui par
défaut de la plateforme (habituellement cc
).
De façon similaire, vous pouvez repositionner les options par défaut du
compilateur à l'aide de la variable CFLAGS
.
Les variables d'environnement peuvent être indiquées sur la ligne de
commande configure
, par exemple :
./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
Voici une liste des variables importantes qui sont configurables de cete façon :
BISON
programme Bison
CC
compilateur C
CFLAGS
options à passer au compilateur C
CPP
préprocesseur C
CPPFLAGS
options à passer au préprocesseur C
DTRACE
emplacement du programme dtrace
DTRACEFLAGS
options à passer au programme dtrace
FLEX
programme Flex
LDFLAGS
options à utiliser lors de l'édition des liens des exécutables et des bibliothèques partagées
LDFLAGS_EX
options supplémentaires valables uniquement lors de l'édition des liens des exécutables
LDFLAGS_SL
options supplémentaires valables uniquement lors de l'édition des liens des bibliothèques partagées
MSGFMT
programme msgfmt
pour le support des langues
PERL
chemin complet vers l'interpréteur Perl. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Perl.
PYTHON
chemin complet vers l'interpréteur Python. Il sera utilisé pour
déterminer les dépendances pour la construction de PL/Python. De
plus, si Python 2 ou 3 est spécifié ici (ou implicitement choisi), il
détermine la variante de PL/Python qui devient disponible. Voir
la documentation PL/Python
Section 45.1 pour plus
d'informations. Si cette variable n'est pas configurée, les suivantes
sont testées dans cet ordre : python python3
python2
.
TCLSH
programme interpréteur Tcl. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Tcl, et il sera substitué dans des scripts Tcl.
XML2_CONFIG
programme xml2-config
utilisé pour localiser
l'installation de libxml2.
Parfois, il est utile d'ajouter des options de compilation à l'ensemble
choisi par configure
après coup. Un exemple parlant
concerne l'option -Werror
de
gcc qui ne peut pas être incluse dans la
variable CFLAGS
passée à configure
,
car il cassera un ggrand nombre de tests internes de
configure
. Pour ajouter de telles options, incluez-
les dans la variable d'environnement COPT
lors de
l'exécution de gmake
. Le contenu de
COPT
est ajouté aux variables CFLAGS
et
LDFLAGS
configurées par configure
.
Par exemple, vous pouvez faire :
gmake COPT='-Werror'
ou
export COPT='-Werror'
gmake
Lors de l'écriture de code à l'intérieur du serveur, il est recommandé
d'utiliser les options --enable-cassert
(qui active
un grand nombre de vérifications d'erreur à l'exécution) et
--enable-debug
(qui améliore l'utilité des outils
de débuggage) de configure.
Si vous utilisez GCC, il est préférable de construire avec un niveau
d'optimisation d'au moins -O1
parce que désactiver
toute optimisation (-O0
) désactive aussi certains
messages importants du compilateur (comme l'utilisation de variables
non initialisées). Néanmoins, les niveaux d'optimisations peuvent
compliquer le débuggage parce que faire du pas à pas sur le code
compilé ne correspondra pas forcément aux lignes de code une à une.
Si vous avez du mal à débugger du code optimisé, recompilez les fichiers
intéressants avec -O0
. Une façon simple de le faire est
de passer une option à make:
make PROFILE=-O0 file.o
.
Les variables d'environnement COPT
et
PROFILE
sont gérées de façon identique par les fichiers
makefile de PostgreSQL. Laquelle utiliser est
une affaire de préférence, mais un usage commun parmi les développeurs
est d'utiliser PROFILE
pour les ajustements inhabituels
alors que COPT
servirait aux variables à configurer à
chaque fois.
Compilation
Pour démarrer la compilation, saisissez
make
(Rappelez-vous d'utiliser GNU make). La compilation prendra quelques minutes, selon votre matériel. La dernière ligne affichée devrait être
All of PostgreSQL successfully made. Ready to install.
Si vous voulez construire tout ce qui peut être construit, ceci incluant la
documentation (HTML et pages man) et les modules supplémentaires
(contrib
), saisissez à la place :
make world
La dernière ligne affichée doit être :
PostgreSQL, contrib, and documentation successfully made. Ready to install.
Si vous voulez compiler tout ce qui peut être compilé, en incluant les
modules supplémentaires (contrib
), mais sans la
documentation, saisissez à la place :
make world-bin
Tests de régression
Si vous souhaitez tester le serveur nouvellement compilé avant de l'installer, vous pouvez exécuter les tests de régression à ce moment. Les tests de régression sont une suite de tests qui vérifient que PostgreSQL fonctionne sur votre machine tel que les développeurs l'espèrent. Saisissez
make check
(cela ne fonctionne pas en tant que root ; faites-le en tant
qu'utilisateur sans droits).
Le fichier src/test/regress/README
et la documentation contiennentLe Chapitre 32 contient
des détails sur l'interprétation des résultats de ces tests. Vous pouvez
les répéter autant de fois que vous le voulez en utilisant la même
commande.
Installer les fichiers
Si vous mettez à jour une version existante, assurez-vous d'avoir bien lu la documentation Section 18.6 qui donne les instructions sur la mise à jour d'un cluster.
Pour installer PostgreSQL, saisissez
make install
Cela installera les fichiers dans les répertoires spécifiés dans l'Étape 1. Assurez-vous d'avoir les droits appropriés pour écrire dans ces répertoires. Normalement, vous avez besoin d'être superutilisateur pour cette étape. Une alternative consiste à créer les répertoires cibles à l'avance et à leur donner les droits appropriées.
Pour installer la documentation (HTML et pages man), saisissez :
make install-docs
Si vous construisez tout, saisissez ceci à la place :
make install-world
Cela installe aussi la documentation.
Si vous voulez tout construire, sauf la documentation, saisissez à la place :
make install-world-bin
Vous pouvez utiliser make install-strip
en lieu et
place de make install
pour dépouiller l'installation
des exécutables et des bibliothèques. Cela économise un peu d'espace disque.
Si vous avez effectué la compilation en mode de débogage, ce dépouillage
l'enlèvera, donc ce n'est à faire seulement si ce mode n'est plus
nécessaire. install-strip
essaie d'être raisonnable
en sauvegardant de l'espace disque mais il n'a pas une connaissance
parfaite de la façon de dépouiller un exécutable de tous les octets
inutiles. Ainsi, si vous voulez sauvegarder le maximum d'espace disque, vous
devrez faire le travail à la main.
L'installation standard fournit seulement les fichiers en-têtes nécessaires
pour le développement d'applications clientes ainsi que pour le développement
de programmes côté serveur comme des fonction personnelles ou des
types de données écrits en C (avant PostgreSQL 8.0, une
commande make install-all-headers
séparée était nécessaire pour
ce dernier point mais cette étape a été intégrée à l'installation standard).
Installation du client uniquement : Si vous voulez uniquement installer les applications clientes et les bibliothèques d'interface, alors vous pouvez utilisez ces commandes :
make -C src/bin install
make -C src/include install
make -C src/interfaces install
make -C doc install
src/bin
comprend quelques exécutables utilisés seulement
par le serveur mais ils sont petits.
Désinstallation :
Pour désinstaller, utilisez la commande make
uninstall
. Cependant, cela ne supprimera pas les répertoires créés.
Nettoyage :
Après l'installation, vous pouvez libérer de l'espace en supprimant les
fichiers issus de la compilation des répertoires sources à l'aide de la
commande make clean
. Cela conservera les fichiers créés par
la commande configure
, ainsi vous pourrez tout recompiler
ultérieurement avec make
. Pour remettre l'arborescence
source dans l'état initial, utilisez make distclean
.
Si vous voulez effectuer la compilation pour diverses plateformes à partir
des mêmes sources vous devrez d'abord refaire la configuration à chaque
fois (autrement, utilisez un répertoire de construction séparé pour chaque
plateforme, de façon à ce que le répertoire des sources reste inchangé).
Si vous avez compilé et que vous vous êtes rendu compte que les options de
configure
sont fausses ou si vous changez quoi que ce soit que
configure
prenne en compte (par exemple, la mise à jour
d'applications), alors faire un make distclean
avant de
reconfigurer et recompiler est une bonne idée. Sans ça, vos changements dans
la configuration ne seront pas répercutés partout où il faut.