Im vorherigen Blogbeitrag haben wir die verschiedenen Windows-Build-Varianten besprochen, die PostgreSQL unterstützt. In diesem Beitrag besprechen wir, wie Sie als Unix-basierter Entwickler überprüfen können, ob Ihr Patch unter Windows funktioniert. (Der Einfachheit halber sage ich „Unix“, um Linux, BSD, macOS und ähnliches zu meinen.)
Erstens gibt es ein paar Möglichkeiten, Ihren Patch zu überprüfen, ohne überhaupt Windows zu haben.
Wenn Ihr Patch das Build-System berührt, beispielsweise durch Hinzufügen neuer Dateien oder wahrscheinlicher durch Hinzufügen von Bedingungen, neuen Build-Optionen oder zusätzlicher Ad-hoc-Logik, kann dies die MSVC-Build-Skripte beschädigen, die die Unix-Makefiles analysieren, wie wir besprochen haben letztes Mal. Aber Sie können diese Skripte auch unter Unix ausführen. Sie enthalten (fast) nichts Windows-spezifisches, da sie eigentlich nur einen Dateisatz parsen und einen anderen erzeugen. Sie können einfach rennen
perl src/tools/msvc/mkvcbuild.pl
und sehen was passiert. Dies funktioniert ab Commit 73c8596. (Vielleicht speichern Sie Ihre Arbeit vorher, da dies einige generierte Dateien überschreiben könnte, die von Ihrer lokalen Nicht-Windows-Konfiguration verwendet werden). Dadurch werden Projektdateien für Visual Studio erstellt, mit denen Sie nicht viel anfangen können, aber Sie können überprüfen, ob das Skript überhaupt ausgeführt wurde, Sie können die Ausgabe vorher und nachher vergleichen oder ob Sie „blind edits“ an einer der Dateien vorgenommen haben Dateien unter src/tools/msvc/ Sie können diese bis zu einem gewissen Grad überprüfen.
Eine andere Möglichkeit besteht darin, Build-Optionen auszuüben, die normalerweise mit Windows verbunden sind. Welche davon nützlich ist, hängt davon ab, was Ihr Patch ändert. Beispielsweise baut Windows mit HAVE_UNIX_SOCKETS undefiniert, daher kann es sich lohnen, dies manuell zu testen, wenn Sie Änderungen am Netzwerkcode vornehmen. (Aber das verschwindet, da Windows jetzt tatsächlich Unix-Domain-Sockets unterstützt.) Ebenso HAVE_WORKING_LINK ist unter Windows undefiniert, obwohl die Auswirkungen davon gering sind (und auch verschwinden; manchmal ist eine Folge des Schreibens von Blog-Beiträgen wie diesem, dass Sie feststellen, dass die Probleme, die Sie beschreiben wollten, überhaupt nicht vorhanden sein sollten, und du gehst sie reparieren). Sie können diese beiden Optionen ändern, indem Sie src/include/pg_config_manual.h bearbeiten . Eine weitere wichtige Option ist EXEC_BACKEND , das den Unix-Stil fork() ersetzt Aufruf mit einem fork() plus exec() Implementierung, die CreateProcess() zugeordnet werden kann unter Windows. Das geht tatsächlich überraschend selten kaputt, aber wenn doch, können Sie es auf einem Unix-System vollständig debuggen und reparieren. Um EXEC_BACKEND zu aktivieren , können Sie entweder src/Makefile.global bearbeiten und fügen Sie -DEXEC_BACKEND hinzu zu CPPFLAGS , oder fügen Sie vielleicht eine Definition zu src/include/pg_config_manual.h hinzu . (Nicht sicher, warum dies anders ist als die anderen; vielleicht eine andere Sache, die irgendwann behoben werden muss. [Update:ebenfalls behoben])
Wenn diese Optionen erschöpft sind, ist es vielleicht an der Zeit, ein echtes Windows-System hochzufahren. Ich möchte zwei Optionen erörtern, die Gelegenheitsentwicklern leicht zur Verfügung stehen. Zunächst können Sie ein Demo-Windows-Image von Microsoft herunterladen und in VirtualBox oder ähnliches importieren. Die aktuellen Links dafür, die ich finden kann, sind:
- https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
- https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
Der zweite davon ist für das Testen von Browsern gedacht, daher ist der erste vielleicht jetzt besser, aber die Route zum Testen von Browsern ist seit einiger Zeit beliebt. Dies sind kostenlose Testversionen, aber bitte lesen Sie die Lizenz selbst.
Zweitens können Sie eine Cloud-Instanz bei einem Cloud-Computing-Anbieter starten. Ich werde sie nicht beim Namen nennen, aber Sie wissen, wer sie sind.
Wenn Sie das Windows-Betriebssystem ausführen, empfehle ich die Installation von MSYS2. (Der erste Download-Link oben von Microsoft hat auch Visual Studio installiert, wenn Sie das bevorzugen.) Verwenden Sie einen Browser (vermutlich Internet Explorer oder wie auch immer es jetzt heißt), um zu msys2.org zu gehen, führen Sie das Installationsprogramm aus und in ein paar Minuten sind Sie fertig wird eine vollständige MSYS2/MinGW-Umgebung bereithalten. Befolgen Sie die Anweisungen auf der Website msys2.org, um den Paketmanager auf den neuesten Stand zu bringen. Öffnen Sie dann eine MinGW-Shell (nicht MSYS2) aus dem Startmenü und führen Sie Folgendes aus, um die für die PostgreSQL-Entwicklung erforderlichen Pakete zu erhalten:
pacman -S git
Jetzt können Sie das Repository mit git klonen. Während das läuft …
pacman -S ${MINGW_PACKAGE_PREFIX}-gcc ${MINGW_PACKAGE_PREFIX}-gettext ${MINGW_PACKAGE_PREFIX}-icu ${MINGW_PACKAGE_PREFIX}-libxml2 ${MINGW_PACKAGE_PREFIX}-libxslt ${MINGW_PACKAGE_PREFIX}-openssl bison flex make diffutils
MINGW_PACKAGE_PREFIX ist eine Umgebungsvariable, die für Sie festgelegt wird, also geben Sie die Befehle so ein. (Dies wird für 32-Bit- und 64-Bit-MinGW unterschiedlich sein.) Die Pakete ohne Präfix sind MSYS2-Pakete (d. h. Cygwin-Pakete). Siehe Teil 1 noch einmal, wenn dies verwirrend ist. An diesem Punkt haben Sie eine vollständige MinGW-Build-Umgebung für PostgreSQL. Sie können configure, make, make check usw. ausführen. Für einige Build-Optionen können zusätzliche Pakete erforderlich sein, aber nicht alle Optionen funktionieren tatsächlich; zum Beispiel keine Readline (verwenden Sie dafür Cygwin).
Im nächsten Teil dieser Serie werde ich mich mit automatischen Build-/Continuous-Integration-Optionen für Windows befassen, die zum Überprüfen von Patches verwendet werden können.
