PostgreSQL開発者として、Windowsでコードを動作させる必要がある場合があります。私は通常Windowsを使用せず、Windowsを永続的にインストールしていないため、これは常に少し面倒です。私はこれを簡単にするためにいくつかのテクニックを開発しました、そしてそれらは共有する価値があると思います。実際、このテキストはかなり長くなったので、これは一連のいくつかのブログ投稿になります。
理解するのに役立つ最初のことは、さまざまなバリアントのWindowsビルドターゲットと、それらがどのように類似しているか、異なるかです。
間違いなく、Windows用にビルドする主な方法は、Microsoft Visual Studioを使用することです。 コンパイラスイート。これは、最もネイティブな環境と考えることができるものです。 PostgreSQL for Windowsのすべてではないにしてもほとんどのバイナリディストリビューションは、このビルドを使用します。このビルドは通常のUnixmakefileを使用しませんが、src/tools/msvc/の下にある別のビルドシステムを使用します 。これにより、makefileが解析され、いくつかのカスタムロジックが作成され、このツールチェーンに固有の「プロジェクト」ファイルが作成されます。これらのファイルを実行してコードを作成できます。ここでは、これをMSVCビルドと呼びましょう。このビルドは2つの方法で壊れがちです。1つはコードが実際にWindowsでビルドまたは実行されない場合、もう1つは通常の（makefilesベースの）ビルドシステムでこれらのアドホックスクリプトを変更する場合です。壊す。ですから、これは常に対処するのがとても楽しいです。
2番目の方法は、 MinGWを使用することです 。これは、GNUツールチェーン（GCC、GNU binutils、GNU ldなど）を使用して、Windows上でネイティブコードを構築します。これは「Windows上のGCC」と考えることができますが、実際には、Windowsシステムライブラリとインターフェイスするための追加のシムと接着剤が含まれています。これは、configureファイルとmakefilesを使用する通常のUnix風のビルドシステムを使用しますが、生成されるコードは、原則としてMSVCビルドの出力と同等のネイティブWindowsコードです。これは、コードがMSVCビルドでビルドまたは実行されない場合、ここでもビルドまたは実行されないことも意味します。ただし、ビルドシステムはLinuxなどと同じなので、誤って壊してしまうことはありません。
3番目の方法はCygwin 。 Cygwinは、Windows上でPOSIXのような環境を提供するサブシステムです。たとえば、Cygwinはユーザー、グループ、fork()を追加します 、SysV共有メモリ、およびネイティブWindowsには存在しないが、たとえばLinuxでは標準であるその他の機能。 LinuxまたはBSD用のソースコードをCygwinで変更せずに（または少なくともUnixライクなシステム間の移植変更の一般的な範囲内にある変更のみで）ビルドできるという考え方です。このため、PostgreSQLのCygwinポートは、ネイティブのWindowsポートよりもずっと前に存在していました。これは、はるかに小さな作業であったためです。実際には、抽象化は一部の領域、特にネットワーキングコードやファイルの命名とアクセスの周辺で機能しなくなりますが、一般に、Cygwinビルドが他のターゲットと比較して機能しなくなることはめったにありません。
以前は、Windowsでビルドする別の方法がありました。 win32.makがありました Windows上のnmakeで直接使用できるファイルであり、ある時点でBorlandコンパイラもサポートされていました。これらは基本的に、完全なネイティブポートが到着する前にWindows上でネイティブにlibpqを構築するための一時的な手段でした。これらは削除されました。
このコンテキストに表示される別の用語があります： MSYS 。この理由は、MinGW自体はあまり役に立たないことが多いためです。これは単なるコンパイラツールチェーンです。ただし、一般的なUnixソフトウェアをビルドするには、bash、make、sed、grepなどの追加ツールと、configureスクリプトまたはmakefileから通常使用されるすべてのものが必要です。これらのツールはすべて、ネイティブWindowsポートとして存在するわけではありません。ただし、Cygwinサブシステム上で実行できます。したがって、MinGWを使用する1つの方法は、Cygwinの内部からです。もう1つはMSYSで、「最小システム」の略です。これは、大まかに言って、Cygwinの特注サブセットと、ソフトウェアの構築にMinGWを使用するためのパッケージです。元のMSYSは現在、私が知る限り放棄されていますが、人気のある新しい代替MSYS2があります。これについては、後続のブログ投稿で詳しく説明します。今のところ、これらすべての異なるソフトウェアパッケージ間の関係を理解してください。
次に、ソースコードがこれらのさまざまなビルド環境をどのように認識するかを考えてみましょう。
MSVCまたはMinGWを使用するネイティブビルドは、_WIN32を定義します 。 （不思議なことに、これは32ビットビルドと64ビットビルドの両方に当てはまります。64ビットビルドでも_WIN64が定義されます。 、ただし、これはめったに使用されません。）PostgreSQLソースコードはWIN32を使用します 代わりに、これはPostgreSQLに固有であり、コンパイラによって実行されるわけではありません。
MSVCは_MSC_VERも定義します いくつかのバージョン番号に。これは、特定のコンパイラバージョンの問題を回避するのに役立つ場合があります（多くの場合、Unixビルドでconfigure forを使用する傾向があります）。 MinGWは_MSC_VERを定義しないことに注意してください 、したがって、それを処理するためにコードを注意深く記述する必要があります。 #if _MSC_VER < NNNNのようなコードのため、これに関していくつかのマイナーなバグがありました。 古いコンパイラの問題を回避することは、MinGWでもトリガーされますが、これは意図されていなかった可能性があります。 （より正確なのは、#if defined(_MSC_VER) && _MSC_VER < NNNN もちろん、#ifdef WIN32にラップします 。）MinGWは__MINGW32__を定義します および__MINGW64__ 、しかしこれらはめったに使用されません。また、MinGWはもちろん__GNUC__を定義します GCCであるため、GCCまたはGCCバージョンに固有の条件付きコードも使用できます。一般に、MinGWはAutoconfを使用するため、これらは通常configureでチェックする必要があります コードではなく。
Cygwinは__CYGWIN__を定義します 。特に、Cygwinは_WIN32を定義していません 、またはWIN32 、など—それ自体がネイティブWindowsであるとは見なされないためです。そのため、WindowsがCygwinの抽象化を覗く一部のコード領域では、#if defined(WIN32) ||のコードが多数表示されます。 両方のケースを処理します。
defined(__CYGWIN__)
（コードには、これらのプリプロセッサ定義のすべてを賢明で一貫した方法で常に処理するとは限らない、ほこりっぽいコーナーがいくつかあります。現実が奇妙であるため、これは意図的なものである場合もあれば、腐敗した誤ったコードである必要がある場合もあります。クリーンアップされました。）
これらの各ターゲットは、原則として32ビットおよび64ビットのバリアントとして存在します。通常の最新のインストールである64ビットWindowsオペレーティングシステムのインストールでは、32ビットと64ビットの両方のソフトウェアを実行できるため、このようなシステムに両方のバリアントをインストールして実行できます。実稼働インストールではおそらく64ビットビルドを使用する必要があるため、32ビット環境を気にしないことを選択できます。実際、Cygwinの32ビットバリアントはかなり死んでいるようであり、まったく機能させることができない可能性があります。ただし、問題の1つは、64ビットのMinGWにはいくつかのあいまいなバグがあることです。したがって、特にMinGWを使用する場合は、オペレーティングシステムやツールチェーンのバグと戦う場合を除いて、32ビット環境を使用する方がよい場合があります。ただし、32ビットコンピューティングは明らかに一般的にほとんど廃止されつつあるため、これは将来性のあるオプションではありません。
ここで問題となるのは、おそらくこれらの環境のどれが「最良」であるかということです。開発に関しては、すべてのコードがそれらすべてで機能する必要があるため、実際には問題ではありません。上で述べたように、MSVCビルドはWindowsのほとんどの実稼働展開に使用されます。 Unixライクな環境に慣れている場合は、MinGW（またはMSYS2）環境の方が開発に適していますが、特に64ビットのMinGW環境は多少バグがあるように思われるため、これを本番環境に推奨することは困難です。 Cygwinは、この時点で歴史的な好奇心であると考える人もいるかもしれません。パフォーマンスが非常に悪いため、Cygwinで本番サーバーを実行することはお勧めしません。しかし、Cygwinは実際にはいくつかの状況で役立ちます。たとえば、ReadlineはどちらのネイティブWindowsビルドでも機能しませんが、Cygwinでは機能するため、psqlユーザーの場合は、Cygwinビルドを使用することをお勧めします。また、Cygwinは、このブログ投稿の逆の状況で役立ちます。あなたはWindowsであり、ほとんどの場合開発者であり、コードがほとんどUnixと互換性があることを確認したいと考えています。したがって、これら3つの環境すべてに価値があり、現時点で維持する価値があります。
このシリーズの次のパートでは、Windowsが主要な開発環境でない場合に、Windows上およびWindows用のコード変更をテストするためのいくつかの手法について説明します。