無料スクリプト配布のPHP.TO   PHPの実用的なtips PHPマニュアル MySQLマニュアル Apacheマニュアル PostgreSQLマニュアル マニュアル検索    

15.4. インストール手順

  1. 構成

    インストール手順の最初のステップは、システムに合わせてソースツリーを設定し、使用するオプションを選択することです。 configure スクリプトを実行することでこれを行います。 デフォルトのインストールを行う場合は、単に以下を入力してください。

    
    ./configure
    

    
    mkdir build_dir
    
    
    cd build_dir
    
    
    /path/to/source/tree/configure [options go here]
    
    
    gmake
    

    デフォルトの構成では、サーバ、ユーティリティの他に、Cコンパイラだけを必要とするクライアントアプリケーションやインタフェースを構築します。 デフォルトでは、全てのファイルは /usr/local/pgsql 以下にインストールされます。

    configure に以下のコマンドラインオプションを1つ以上指定することで、構築処理やインストール処理を変更することができます。

    --prefix= PREFIX

    /usr/local/pgsql ではなく、 PREFIX ディレクトリ以下に全てのファイルをインストールします。 ファイルは実際には様々なサブディレクトリにインストールされ、 PREFIX ディレクトリの直下にインストールされるファイルはありません。

    特別な必要性があるのであれば、以下のオプションを使用して個々のサブディレクトリを変更することもできます。 しかし、これらをそのまま使用した場合、インストレーションは位置再変更可能になります。 つまり、インストールの後にディレクトリを移動することができます ( man doc の場所はこの影響を受けません。)

    インストールの位置再変更のために、 configure --disable-rpath を使用しようと考えるかもしれません。 その場合は、オペレーティングシステムにその共有ライブラリの場所を通知する必要があるでしょう。

    --exec-prefix= EXEC-PREFIX

    アーキテクチャ依存のファイルを PREFIX の設定とは別の接頭辞 EXEC-PREFIX 以下にインストールすることができます。 ホスト間でアーキテクチャ非依存のファイルを共有する場合に便利です。 省略した場合、 EXEC-PREFIX PREFIX と同じに設定され、アーキテクチャに依存するファイルも非依存なファイルも同じツリー以下にインストールされます。 ほとんどの場合、これが望まれています。

    --bindir= DIRECTORY

    実行可能プログラム用のディレクトリを指定します。 デフォルトでは EXEC-PREFIX /bin であり、通常 /usr/local/pgsql/bin となります。

    --sysconfdir= DIRECTORY

    各種設定ファイル用のディレクトリを設定します。 デフォルトでは PREFIX /etc です。

    --libdir= DIRECTORY

    ライブラリや動的ロード可能モジュールをインストールする場所を設定します。 デフォルトは EXEC-PREFIX /lib です。

    --includedir= DIRECTORY

    CおよびC++のヘッダファイルをインストールするディレクトリを設定します。 デフォルトは PREFIX /include です。

    --datarootdir= DIRECTORY

    いろいろな種類の読み取り専用データファイル用のルートディレクトリを設定します。これは後述のオプションの一部についてのデフォルトを設定するだけです。デフォルトは PREFIX /share です。

    --datadir= DIRECTORY

    インストールプログラムが使用する読み取り専用のディレクトリを設定します。デフォルトは DATAROOTDIR です。これはインストールするデータベースファイルがどこに設置されるかとは関係ないことを覚えておいてください。

    --localedir= DIRECTORY

    特にメッセージ翻訳カタログファイルのロケールデータをインストールするディレクトリを設定します。デフォルトは DATAROOTDIR /locale です。

    --mandir= DIRECTORY

    PostgreSQL 付属のマニュアルページがこのディレクトリ以下の、対応する man x サブディレクトリにインストールされます。 デフォルトは DATAROOTDIR /man です。

    --docdir= DIRECTORY

    "man" ページを除いた、ドキュメント一式ファイルをインストールするルートディレクトリを設定します。これは以下のオプションのデフォルトのみを設定します。このオプションのデフォルト値は DATAROOTDIR /doc/postgresql です。

    --htmldir= DIRECTORY

    PostgreSQL のHTML形式化文書一式はこのディレクトリの下にインストールされます。デフォルトは DATAROOTDIR です。

    注意: /usr/local/include といった)共用のインストール場所に、システムの他の名前空間に影響を与えることなく PostgreSQL をインストールすることができるような配慮がなされています。 まず、完全に展開したディレクトリ名に " postgres " " pgsql " という文字列が含まれていない場合、 " /postgresql " という文字列が自動的に datadir sysconfdir docdir に追加されます。 例えば、接頭辞として /usr/local を使用する場合、文書は /usr/local/doc/postgresql にインストールされますが、接頭辞が /opt/postgres の場合は /opt/postgres/doc にインストールされます。 クライアントインタフェース用の外部向けCヘッダファイルは includedir にインストールされ、名前空間の問題はありません。 内部向けヘッダファイルやサーバ用ヘッダファイルは、 includedir 以下の非公開ディレクトリにインストールされます。 各インタフェース用のヘッダファイルにアクセスする方法についての情報は、そのインタフェースの文書を参照してください。 最後に、適切であれば、動的ロード可能モジュール用に libdir 以下にも非公開用のサブディレクトリが作成されます。

    --with-includes= DIRECTORIES

    DIRECTORIES には、コンパイラがヘッダファイルを検索するディレクトリのリストをコロンで区切って指定します。 (GNU Readline などの)オプションのパッケージが非標準的な場所にインストールされている場合、このオプションと、おそらく対応する --with-libraries オプションを使用する必要があります。

    例: --with-includes=/opt/gnu/include:/usr/sup/include

    --with-libraries= DIRECTORIES

    DIRECTORIES には、ライブラリを検索するディレクトリのリストをコロンで区切って指定します。 パッケージが非標準的な場所にインストールされている場合は、おそらくこのオプション(と対応する --with-includes オプション)を使用する必要があります。

    例: --with-libraries=/opt/gnu/lib:/usr/sup/lib

    --enable-nls[ = LANGUAGES ]

    各国語サポート( NLS )、つまり、英語以外の言語によるプログラムメッセージの表示機能を有効にします。 LANGUAGES はオプションであり、サポートさせたい言語コードを空白で区切ったリストを指定します。例えば、 --enable-nls='de fr' などとします (指定したリストと実際に用意された翻訳との論理積が自動的に計算されます)。 リストに何も指定しなかった場合、利用可能な翻訳すべてがインストールされます。

    このオプションを使用するためには、 gettext APIの実装が必要です。 上記を参照してください。

    --with-pgport= NUMBER

    サーバとクライアントのデフォルトのポート番号を NUMBER に設定します。 デフォルトは5432です。 このポートは後でいつでも変更することができますが、ここで指定した場合、サーバとクライアントはコンパイル時に同じデフォルト値を持つようになります。 これは非常に便利です。 通常、デフォルト以外の値を選択すべき唯一の理由は、同じマシンで複数の PostgreSQL を稼働させることです。

    --with-perl

    PL/Perl サーバサイド言語を構築します。

    --with-python

    PL/Python サーバサイド言語を構築します。

    --with-tcl

    PL/Tcl サーバサイド言語を構築します。

    --with-tclconfig= DIRECTORY

    Tclは、Tclへのインタフェースモジュールを構築するために必要な設定情報を含む tclConfig.sh ファイルをインストールします このファイルは通常、自動的に一般的に知られている場所にありますが、もしTclの別のバージョンを使いたい場合は、検索対象のディレクトリを指定することができます。

    --with-gssapi

    GSSAPI認証のサポートを構築します。 多くのシステムでは、GSSAPIシステム(通常Kerberosインストレーションの一部)はデフォルトの検索場所(例えば /usr/include /usr/lib )にインストールされていません。 そのため、 --with-includes --with-libraries オプションをさらに追加して使わなければいけません。 configure は、処理を進める前にGSSAPIが正しくインストールされていることを確認するために、必要とされるヘッダファイルとライブラリを検査します。

    --with-krb5

    Kerberos 5 認証のサポートを構築します。 多くのシステムでは、Kerberosシステムはデフォルトの検索場所(例えば /usr/include /usr/lib )にインストールされていません。 そのため、 --with-includes --with-libraries オプションをさらに追加して使わなければいけません。 configure は、処理を進める前にKerberosが正しくインストールされていることを確認するために、必要とされるヘッダファイルとライブラリを検査します。

    --with-krb-srvnam= NAME

    Kerberos のサービスプリンシパルのデフォルトの名前です(GSSAPIでも使用されます)。 デフォルトでは "postgres" です。 これを変える理由はWindows環境がない限り、特にありません。 Windows環境がある場合は大文字の POSTGRES に設定する必要があります。

    --with-openssl

    SSL (暗号化)接続のサポートを有効にして構築します。 これには、 OpenSSL パッケージがインストールされていなければなりません。 configure は、処理を進める前に OpenSSL のインストールを確認するために、必要なヘッダファイルとライブラリを検査します。

    --with-pam

    PAM (プラガブル認証モジュール)のサポートを有効にして構築します。

    --with-ldap

    認証および接続パラメータ検索用の LDAP サポートを有効にして構築します。 ( 項31.17 および 項19.3.8 を参照してください。) Unixでは、 OpenLDAP パッケージがインストールされていることが要求されます。Windowsではデフォルトの WinLDAP ライブラリが使用されます。 configure は、処理を進める前に OpenLDAP のインストールが十分されているかどうかを確認するために、必要なヘッダファイルとライブラリを検査します。

    --without-readline

    Readline ライブラリ(および libedit )の使用を防止します。 これにより psql でのコマンドライン編集および履歴が無効となるため、推奨されません。

    --with-libedit-preferred

    GPLライセンスの Readline ではなくBSDライセンスの libedit ライブラリを優先して使用します。 このオプションは両方のライブラリがインストールされている場合にのみ重要です。 この場合デフォルトで Readline が使用されます。

    --with-bonjour

    Bonjourサポートを有効にして構築します。 これにはオペレーティングシステムがBonjourをサポートしていることが必要です。 Mac OS Xでは推奨します。

    --with-ossp-uuid

    ビルドに OSSP UUIDライブラリ を使用します。 具体的には、UUIDを生成する関数を提供する uuid-ossp モジュールを構築します。

    --with-libxml

    libxmlを使用して構築します(SQL/XMLサポートが有効になります)。 この機能のためにはlibxmlバージョン2.6.23以降が必要です。

    libxmlがインストールする xml2-config プログラムを使用して、必要なコンパイラオプション、リンクオプションを検出することができます。 PostgreSQLは、見つけられればこのプログラムを使用します。 通常以外の場所にインストールしたlibxmlインストレーションを指定するためには、環境変数 XML2_CONFIG がそのインストレーション用の xml2-config プログラムを指し示すように設定してください。 または、 --with-includes および --with-libraries を使用してください。

    --with-libxslt

    xml2 モジュールを構築する場合はlibxsltを使用してください。 xml2 はXMLのXSL変換を行うために、このライブラリに依存します。

    --disable-integer-datetimes

    日付時刻および時間間隔の格納に64ビット整数格納方式を無効にし、その代わり浮動小数点で格納します。 PostgreSQL リリース8.4以前では日付時刻の浮動小数点格納方式がデフォルトでしたが、 timestamp 値がとる値の全ての範囲でマイクロ秒精度をサポートしないため現在非推奨となりました。しかし、整数ベースの日付時刻格納には64-ビット整数型が必要です。従って、このオプションはこの型が使えない場合での使用、または以前の PostgreSQL バージョン用に書かれたアプリケーションとの互換性を保たなければならない場合に使用します。 詳細は 項8.5 を参照してください。

    --disable-float4-byval

    float4値の "値" 渡しを無効にし、 "参照" 渡しで渡すようにします。 このオプションは性能に関するコストがかかりますが、C言語で開発された古いユーザ定義の関数との互換性を保持する場合や "version 0" 呼び出し規約を使用する場合に必要になります。 長期的に見てより良い解決方法はこうした関数を更新して、 "version 1" 呼び出し規約を使用するようにすることです。

    --disable-float8-byval

    float8値の "値" 渡しを無効にし、 "参照" 渡しで渡すようにします。 このオプションは性能に関するコストがかかりますが、C言語で開発された古いユーザ定義の関数との互換性を保持する場合や "version 0" 呼び出し規約を使用する場合に必要になります。 長期的に見てより良い解決方法はこうした関数を更新して、 "version 1" 呼び出し規約を使用するようにすることです。 このオプションはfloat8のみだけに影響するのではなく、int8やタイムスタンプなど一部の関連した型についても影響することに注意してください。 32ビットプラットフォームでは、 --disable-float8-byval がデフォルトで --enable-float8-byval を選択することはできません。

    --with-segsize= SEGSIZE

    セグメントサイズ をギガバイト単位で指定します。 大規模なテーブルはこのセグメントサイズと同じサイズの複数のオペレーティングシステムのファイルに分割されます。 これにより多くのプラットフォームで存在するファイルサイズ上限に関する問題を防ぎます。 デフォルトのセグメントサイズは1ギガバイトで、サポートされるすべてのプラットフォームで安全です。 使用するオペレーティングシステムが "ラージファイル" をサポートしていれば(最近はほとんどサポートしています)、より大きなセグメントサイズを使用することができます。 非常に大規模なテーブルで作業する時のファイル記述子の消費数を減らすために、これが役に立つことができます。 しかし、プラットフォーム、または使用予定のファイルシステムでサポートされる値以上に大きな値を指定しないように注意してください。 tar などの使用したい、その他のツールにも使用できるファイルサイズに制限があることがあります。 絶対に必要ではありませんが、この値を2のべき乗にすることを勧めます。 この値の変更にはinitdbが必要であることに注意してください。

    --with-blocksize= BLOCKSIZE

    キロバイト単位で ブロック容量 を設定します。これはテーブル内でのストレージとI/O単位です。8キロバイトのデフォルトはほとんどの場合適切ですが、特別な場合は他の値が役立ちます。値は1から32(キロバイト)の範囲の2のべき乗でなければなりません。この値の変更はinitdbを必要とすることを覚えておいてください。

    --with-wal-segsize= SEGSIZE

    メガバイト単位で WALセグメント容量 を設定します。これはWALログ内のそれぞれ個別のファイルの容量です。この容量を調整することで、WALログ配送の粒度を制御するのに役立ちます。デフォルト容量は16メガバイトです。1から64(メガバイト)の範囲の2のべき乗でなければなりません。この値の変更はinitdbを必要とすることを覚えておいてください。

    --with-wal-blocksize= BLOCKSIZE

    キロバイト単位で WALブロック容量 を設定します。これはこれはWALログ内でのストレージとI/O単位です。8キロバイトのデフォルトはほとんどの場合適切ですが、特別な場合は大きめの値が役立ちます。値は1から64(キロバイト)の範囲の2のべき乗でなければなりません。この値の変更はinitdbを必要とすることを覚えておいてください。

    --disable-spinlocks

    PostgreSQL がそのプラットフォーム用のCPUスピンロックをサポートしない場合でも、構築に成功するようにします。 スピンロックのサポートの欠落により、性能は悪化します。 したがって、このオプションは、構築が失敗し、その原因が使用するプラットフォームでスピンロックサポートが欠落している場合にのみ使用してください。 使用するプラットフォームにおける PostgreSQL の構築にこのオプションが必要とされた場合は、 PostgreSQL 開発者にその問題を報告してください。

    --disable-thread-safety

    クライアントライブラリのスレッドセーフを無効にします。 これにより、 libpq ECPG プログラム内の同時実行スレッドは、安全にその固有の接続ハンドルを制御できなくなります。

    --with-system-tzdata= DIRECTORY

    PostgreSQL は、日付時刻に関する操作で必要な、独自の時間帯データベースを持ちます。 実際のところ、この時間帯データベースはFreeBSD、Linux、Solarisなどの多くのオペレーティングシステムで提供される "zoneinfo" 時間帯データベースと互換性があります。 このため、これを再びインストールすることは冗長です。 このオプションが使用されると、 DIRECTORY にあるシステムが提供する時間帯データベースがPostgreSQLソース配布物に含まれるものの代わりに使用されます。 DIRECTORY は絶対パスで指定しなければなりません。 /usr/share/zoneinfo がオペレーティングシステムの一部でよく使われます。 インストール処理が時間帯データが一致しない、またはエラーがあることを検知しないことに注意してください。 このオプションを使用する場合、指定した時間帯データが PostgreSQL で正しく動作するかどうかを検証するためにリグレッションテストを実行することが推奨されています。

    このオプションの主な目的は、対象オペレーティングシステムを熟知しているパッケージ配布者向けです。 このオプションを使用する大きな利点は、多くの局所的な夏時間規則の変更があってもPostgreSQLパッケージを更新する必要がないことです。 他の利点として、時間帯データベースファイルをインストール時に構築する必要がありませんので、PostgreSQLのクロスコンパイルをより簡単に行うことができます。

    --without-zlib

    Zlib ライブラリの使用を抑制します。 これは、 pg_dump pg_restore における圧縮アーカイブのサポートを無効にします。 このオプションは、このライブラリが利用できないごく少数のシステム向けだけのものです。

    --enable-debug

    全てのプログラムとライブラリをデバッグシンボル付きでコンパイルします。 これは、問題を解析するためにデバッガ内のプログラムを実行できることを意味します。 これはインストールする実行形式ファイルのサイズをかなり大きくし、また、GCC以外のコンパイラでは、通常はコンパイラによる最適化が行われなくなりますので、低速になります。 しかし、デバッグシンボルが利用できるということは、発生した問題に対応する時に非常に便利です。 現在のところ、GCC を使用している場合にのみ、稼働用のインストレーションにこのオプションを使用することを推奨します。 しかし、開発作業時やベータ版を実行する時は、常にこれを有効にすべきです。

    --enable-coverage

    GCCを使用している場合、すべてのプログラムとライブラリはコードカバレッジ試験機構付きでコンパイルされます。 実行すると、これらは構築用ディレクトリ内にコードカバレッジメトリックを持ったファイルを生成します。 詳細は 項30.4 を参照してください このオプションはGCC専用であり、また、開発作業中に使用するためのものです。

    --enable-profiling

    GCCを使用する場合、すべてのプログラムとライブラリがプロファイリング可能状態でコンパイルされます。 バックエンドの終了時、プロファイリングに使用する gmon.out ファイルを含むサブディレクトリが作成されます。 このオプションはGCCを使用する場合のみ使用でき、開発作業を行う時に使用します。

    --enable-cassert

    サーバにおける、多くの "あり得ない" 状態をテストする アサーション チェックを有効にします。 これは、プログラムの開発のためには測り知れない価値がありますが、このテストによりサーバはかなり低速になります。 また、このテストを有効にすると、サーバの安定性を向上させるとは限りません! アサーションチェックは、重要度によって分類されていませんので、比較的害がないようなバグでも、アサーション失敗をトリガとした、サーバの再起動が行われてしまいます。 稼働用にこのオプションを使用することは推奨されませんが、開発作業時やベータ版を実行する場合は、これを有効にすべきです。

    --enable-depend

    自動依存関係追跡を有効にします。 このオプションを使用すると、ヘッダファイルが変更された場合に、影響を受ける全てのオブジェクトファイルが再構築されるように、makefile が設定されます。 これは開発作業時には有用ですが、単に一度コンパイルしインストールするだけであれば、これは無駄なオーバーヘッドです。 現在のところ、GCC でのみ、このオプションは動作します。

    --enable-dtrace

    動的追跡ツールDTraceのサポートを有効にして PostgreSQL をコンパイルします。より詳細な情報は 項27.4 を参照してください。

    dtrace プログラムを指し示すために DTRACE 環境変数を設定することができます。 dtrace は通常、検索パス内に存在しない可能性がある /usr/sbin 以下にインストールされていますので、この設定はよく必要になります。

    さらに dtrace プログラム用のコマンドラインオプションを DTRACEFLAGS 環境変数で指定することができます。 Solarisで64ビットバイナリでDTraceをサポートするには、 DTRACEFLAGS="-64" をconfigureに指定してください。 例えばGCCコンパイラを使用する場合は以下のようにします。

    ./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...

    Sunのコンパイラを使用する場合は以下のようにします。

    ./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...

    configure が選ぶものと違うCコンパイラを使いたいという場合には、 CC 環境変数をその使用したいプログラムに設定することができます。 デフォルトでは、 configure は利用できるのであれば gcc を、利用できなければプラットフォームのデフォルト(通常 cc )を選択します。 同様に、デフォルトのコンパイラフラグは必要に応じて CFLAGS 変数で上書きすることもできます。

    次のようにして、 configure コマンドラインに環境変数を指定することができます。

    
    ./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
    

    以下は、この方式で設定可能な重要な環境変数の一覧です。

    BISON

    Bisonプログラム。

    CC

    Cコンパイラ。

    CFLAGS

    Cコンパイラに渡すオプション。

    CPP

    Cプリプロセッサ。

    CPPFLAGS

    Cプリプロセッサに渡すオプション。

    DTRACE

    dtrace プログラムの場所。

    DTRACEFLAGS

    dtrace プログラムに渡すオプション。

    FLEX

    Flexプログラム。

    LDFLAGS

    実行ファイルや共有ライブラリにリンクする場合に使用するオプション。

    LDFLAGS_EX

    実行ファイルのリンク時のみに追加されるオプション。

    LDFLAGS_SL

    共有ライブラリのリンク時のみに追加されるオプション。

    MSGFMT

    多言語サポート(NLS)用の msgfmt プログラム。

    PERL

    Perlインタプリタのフルパス。 これは、PL/Perl構築に関する依存性を決定するために使用されます。

    PYTHON

    Pythonインタプリタのフルパス。 これは、PL/Python構築に関する依存性を決定するために使用されます。またここでPython 2または3を指定するかどうかで(あるいは暗黙的に選択されます)、どちらのPL/Python言語が利用可能になるかも決まります。 項43.1 を参照してください。

    TCLSH

    Tclインタプリタのフルパスです。 これは、PL/Tcl構築に関する依存性を決定するために使用され、Tclスクリプト内を置き換えます。

    XML2_CONFIG

    libxmlインストレーションの場所を特定するために使用する xml2-config プログラムです。

    注意: サーバ内部のコード開発を行う場合、 --enable-cassert (多数の実行時エラーチェックを有効にする)オプションと --enable-debug (デバッグツールの利便性を向上させる)オプションの使用を推奨します。

    GCCを使う場合、少なくとも -O1 レベルの最適化で構築することがベストです。なぜなら、何の最適化もしない( -O0 ) と、重要なコンパイル警告(初期化されていない変数の使用など)が無効になるからです。 しかし、最適化を行うことでソースコードとコンパイルされたコードのステップは1対1とはならなくなるため、デバッグは複雑になるかもしれません。 最適化されたコードのデバッグに悩まされてしまう場合は、関心のある特定のファイルに対して -O0 で再コンパイルしてください。 これを実行するための簡単な方法は、 gmake PROFILE=-O0 file.o のように、 make 経由でオプションを渡すことです。

  2. 構築

    構築作業を開始するには、以下を入力してください。

    
    gmake
    

    GNU make を使用することを忘れないでください。) ハードウェアに依存しますが、構築作業には数分かかります。 最後に以下のような行が表示されるはずです。

    All of PostgreSQL is successfully made. Ready to install.

    もし、ドキュメント(HTMLやman)や追加モジュール( contrib )を含め、構築可能なもの全てを構築したい場合、次の様に実施します。

    
    gmake world
    

    最終行は次のように表示されるはずです。

    PostgreSQL, contrib and HTML documentation successfully made. Ready to install.

  3. リグレッションテスト

    インストールを行う前に、新しく構築したサーバをテストしたい場合、この時点でリグレッションテストを実行することができます。 リグレッションテストとは、使用するマシンにおいて PostgreSQL が、開発者の想定通りに動作することを検証するためのテストのまとまりです。 次のように入力します。

    
    gmake check
    

    (これは root では動作しません。 非特権ユーザとして実行してください。) 第30章 にはテスト結果の表示に関する詳しい情報があります。 同じコマンドを入力することで、後にいつでもテストを繰り返すことができます。

  4. ファイルのインストール

    注意: もし既存のシステムのアップグレードをする場合、DBクラスタのアップグレードの解説が記載されている 項17.6 を参照してください。

    PostgreSQL をインストールするには、以下を入力してください。

    
    gmake install
    

    これは、ファイルを ステップ1 で指定されたディレクトリにインストールします。 その領域に書き込むための権限を持っていることを確認してください。 通常はこのステップはrootで行う必要があります。 代わりに対象とするディレクトリを前もって作成し、適切に権限を調整することも可能です。

    ドキュメント(HTMLやman)をインストールするには、以下を入力して下さい。

    
    gmake install-docs
    

    先にすべてを(worldを付けて)構築していた場合には、代わりに以下を実行してください。

    
    gmake install-world
    

    これによりドキュメントもインストールされます。

    gmake install の代わりに gmake install-strip を使用することで、インストール時に実行可能ファイルやライブラリをストリップ(strip)することができます。 これにより、多少の容量を節約できます。 デバッグをサポートするように構築している場合でも、ストリップするとデバッグのサポートは実質、除去されてしまいます。 したがって、これはデバッグが必要なくなった場合にのみ実行すべきです。 install-strip は容量を節約するために適切な作業を行おうとしますが、実行可能ファイルから全ての不必要なバイトを完全にストリップすることはできません。 可能な限りのディスク容量を全て節約したい場合は、手動で作業を行う必要があります。

    この標準的なインストール方法では、クライアントアプリケーションの開発に必要なヘッダファイルと、Cで独自の関数やデータ型を作成するといったサーバ側のプログラムの開発用のヘッダファイルが用意されます ( PostgreSQL 8.0より前まででは、後で別途 gmake install-all-headers コマンドが必要でした。しかし、この手順は標準のインストールに含まれるようになりました)。

    クライアント側のみのインストール:. クライアントアプリケーションとインタフェースライブラリのみをインストールしたい場合、下記のコマンドを使います。

    
    gmake -C src/bin install
    
    
    gmake -C src/include install
    
    
    gmake -C src/interfaces install
    
    
    gmake -C doc install
    

    src/bin にはサーバ用の数個のバイナリがあります。これらは小さなものです。

アンインストール:. インストールを取り消すには、 gmake uninstall コマンドを使います。しかし、作成済みのディレクトリは削除されません。

クリーニング:. インストールが終わったら、 gmake clean コマンドを使ってソースツリーから構築用のファイルを削除し、ディスク領域を解放することができます。 configure プログラムが作るファイルは保持されますので、後で gmake コマンドですべてを再構築できます。 ソースツリーを配布された時の状態に戻したい場合は、 gmake distclean コマンドを使います。 同じソースツリー内で複数のプラットフォーム向けに構築する場合、これを実行して、それぞれのプラットフォームに対し再構成しなければなりません。 (または、未変更のソースツリーを維持するために、各プラットフォームで別々の構築用ツリーを使用してください。)

構築作業を行った後で configure 用オプションが間違っていることに気付いた場合や、 configure の調査結果に何らかの変更を加えた場合(例えば、ソフトウェアのアップグレードなど)、再設定と再構築の前に gmake distclean を行うことをお勧めします。 さもないと、設定選択肢の変更は、必要なところ全てには反映されない可能性があります。


powered by SEO.CUG.NET