I det forrige blogindlæg diskuterede vi de forskellige Windows-byggevarianter, som PostgreSQL understøtter. I dette indlæg vil vi diskutere, hvordan du som Unix-baseret udvikler kan kontrollere, om din patch muligvis virker på Windows. (For nemheds skyld vil jeg sige "Unix" for at betyde Linux, BSD, macOS og lignende.)
For det første er der et par måder at tjekke din patch på uden at skulle have Windows overhovedet.
Hvis din patch berører build-systemet, for eksempel ved at tilføje nye filer, eller mere sandsynligt ved at tilføje betingelser, nye build-indstillinger eller yderligere ad-hoc-logik, kan den bryde MSVC build-scripts, som parser Unix make-filerne, som vi diskuterede sidste gang. Men du kan faktisk også køre disse scripts på Unix. Der er (næsten) intet specifikt for Windows i dem, da det eneste, de i virkeligheden gør, er at analysere et sæt filer og producere et andet. Du kan bare køre
perl src/tools/msvc/mkvcbuild.pl
og se hvad der sker. Dette virker fra commit 73c8596. (Måske gemme dit arbejde på forhånd, fordi dette kan overskrive nogle genererede filer, der bruges af din lokale ikke-Windows-konfiguration). Dette vil producere projektfiler til Visual Studio, som du ikke kan gøre meget med, men du kan kontrollere, om scriptet overhovedet kørte, du kan sammenligne output før og efter, eller hvis du har lavet "blind redigeringer" til nogen af filer under src/tools/msvc/ du kan verificere dem til en vis grad.
En anden måde er at udøve byggemuligheder, der typisk er forbundet med Windows. Hvilken af disse der er nyttig afhænger af, hvad din patch ændrer. For eksempel bygger Windows med HAVE_UNIX_SOCKETS udefineret, så at teste det manuelt kan være umagen værd, hvis du laver ændringer i netværkskoden. (Men dette forsvinder, da Windows faktisk understøtter Unix-domæne-sockets nu.) På samme måde, HAVE_WORKING_LINK er udefineret på Windows, selvom virkningen af det er lille (og den forsvinder også; nogle gange er en konsekvens af at skrive blogindlæg som denne at opdage, at de problemer, du ville beskrive, ikke burde være der i første omgang, og du går og reparerer dem). Du kan ændre begge disse muligheder ved at redigere src/include/pg_config_manual.h . En anden vigtig mulighed er EXEC_BACKEND , som erstatter Unix-stilen fork() opkald med en fork() plus exec() implementering, der kan tilknyttes CreateProcess() på Windows. Dette går faktisk overraskende sjældent i stykker, men hvis det gør det, kan du fejlsøge og rette det helt på et Unix-system. For at aktivere EXEC_BACKEND , kan du enten redigere src/Makefile.global og tilføj -DEXEC_BACKEND til CPPFLAGS , eller måske tilføje en definition til src/include/pg_config_manual.h . (Ikke sikker på, hvorfor dette er forskelligt fra de andre; måske en anden ting at rette engang. [opdatering:også rettet])
Når disse muligheder er udtømte, så er det måske på tide at skrue et rigtigt Windows-system op. Jeg vil diskutere to muligheder, der er let tilgængelige for den afslappede udvikler. Først kan du downloade et demo Windows-billede fra Microsoft og importere det til VirtualBox eller noget lignende. De aktuelle links til det, som jeg kan finde, er:
- https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
- https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
Den anden af disse er beregnet til browsertest, så måske er den første bedre nu, men browser-testruten har været populær i nogen tid. Disse er gratis evalueringseksemplarer, men læs venligst licensen selv.
For det andet kan du starte en cloud-instans hos en cloud computing-udbyder. Jeg vil ikke nævne dem, men du ved, hvem de er.
Når du har Windows-operativsystemet kørende, anbefaler jeg at installere MSYS2. (Det første downloadlink ovenfor fra Microsoft har også Visual Studio installeret, hvis du foretrækker det.) Brug en browser (formodentlig Internet Explorer eller hvad den nu hedder) til at gå til msys2.org, køre installationsprogrammet, og i løbet af få minutter kan du vil have et komplet MSYS2/MinGW-miljø klar. Følg instruktionerne på msys2.org-webstedet for at få pakkehåndteringen opdateret. Åbn derefter en MinGW (ikke MSYS2) shell fra Start-menuen og kør følgende for at få de nødvendige pakker til PostgreSQL-udvikling:
pacman -S git
Nu kan du git-klone depotet. Mens det kører …
pacman -S ${MINGW_PACKAGE_PREFIX}-gcc ${MINGW_PACKAGE_PREFIX}-gettext ${MINGW_PACKAGE_PREFIX}-icu ${MINGW_PACKAGE_PREFIX}-libxml2 ${MINGW_PACKAGE_PREFIX}-MINGW_PACKAGE_PREFIX}-MINGW_PACKAGE_PREFIX}-gettext ${MINGW_PACKAGE_PREFIX}-icu ${MINGW_PACKAGE_PREFIX}-libxml2 ${MINGW_PACKAGE_PREFIX}-MINGW_PACKAGE_PREFIX}-MINGW_PACKAGE_PREFIX}-MINGW_PACKAGE_PREFIX}-{MINGW_PACKAGE_PREFIXs}låbn flexon
MINGW_PACKAGE_PREFIX er en miljøvariabel, der er indstillet til dig, så skriv kommandoerne på den måde. (Det vil være forskelligt for 32-bit og 64-bit MinGW.) Pakkerne uden præfiks er MSYS2 (dvs. Cygwin) pakker. Se del 1 igen, hvis dette er forvirrende. På dette tidspunkt har du et komplet MinGW-byggemiljø til PostgreSQL. Du kan køre konfigurere, foretage, foretage kontrol og så videre. Yderligere pakker kan være nødvendige for nogle byggemuligheder, men ikke alle muligheder fungerer faktisk; for eksempel ingen Readline (brug Cygwin til det).
I den næste del af denne serie vil jeg se på muligheder for automatisk build/kontinuerlig integration til Windows, der kan bruges til at verificere patches.