I det tidigare blogginlägget diskuterade vi de olika Windows-byggvarianterna som PostgreSQL stöder. I det här inlägget kommer vi att diskutera hur du som Unix-baserad utvecklare kan kontrollera om din patch kanske fungerar på Windows. (För enkelhetens skull säger jag "Unix" för att betyda Linux, BSD, macOS och liknande.)
För det första finns det några sätt att kontrollera din patch utan att behöva ha Windows alls.
Om din patch berör byggsystemet, till exempel genom att lägga till nya filer, eller mer troligt genom att lägga till villkor, nya byggalternativ eller ytterligare ad-hoc-logik, kan den bryta MSVC-byggskripten, som analyserar Unix-makefilerna, som vi diskuterade förra gången. Men du kan faktiskt köra dessa skript på Unix också. Det finns (nästan) inget specifikt för Windows i dem, eftersom allt de egentligen gör är att analysera en uppsättning filer och producera en annan. Du kan bara springa
perl src/tools/msvc/mkvcbuild.pl
och se vad som händer. Detta fungerar från och med commit 73c8596. (Kanske spara ditt arbete i förväg, eftersom detta kan skriva över vissa genererade filer som används av din lokala icke-Windows-konfiguration). Detta kommer att producera projektfiler för Visual Studio som du inte kan göra så mycket med, men du kan kontrollera om skriptet kördes alls, du kan jämföra utdata före och efter, eller om du har gjort "blinda redigeringar" till någon av filer under src/tools/msvc/ du kan verifiera dem till viss del.
Ett annat sätt är att utöva byggalternativ som vanligtvis är associerade med Windows. Vilken av dessa som är användbar beror på vad din patch ändras. Till exempel bygger Windows med HAVE_UNIX_SOCKETS odefinierad, så att testa det manuellt kan vara värt besväret om du gör ändringar i nätverkskoden. (Men detta försvinner, eftersom Windows faktiskt stöder Unix-domänsockets nu.) På samma sätt, HAVE_WORKING_LINK är odefinierat på Windows, även om effekten av det är liten (och den försvinner också; ibland är en konsekvens av att skriva blogginlägg som detta att upptäcka att problemen du ville beskriva inte borde finnas där i första hand, och du går och fixar dem). Du kan ändra båda dessa alternativ genom att redigera src/include/pg_config_manual.h . Ett annat viktigt alternativ är EXEC_BACKEND , som ersätter fork() i Unix-stil anrop med en fork() plus exec() implementering som kan mappas till CreateProcess() på Windows. Detta går faktiskt sönder förvånansvärt sällan, men om det gör det kan du felsöka och fixa det helt och hållet på ett Unix-system. För att aktivera EXEC_BACKEND , du kan antingen redigera src/Makefile.global och lägg till -DEXEC_BACKEND till CPPFLAGS , eller kanske lägg till en definition till src/include/pg_config_manual.h . (Osäker på varför detta skiljer sig från de andra; kanske en annan sak att fixa någon gång. [uppdatering:även fixat])
När dessa alternativ är uttömda är det kanske dags att snurra upp ett riktigt Windows-system. Jag vill diskutera två alternativ som är lätt tillgängliga för den tillfälliga utvecklaren. Först kan du ladda ner en demo Windows-bild från Microsoft och importera den till VirtualBox eller något liknande. De nuvarande länkarna för det som jag kan hitta är:
- https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
- https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
Den andra av dessa är avsedd för webbläsartestning, så kanske den första är bättre nu, men webbläsartestvägen har varit populär under en tid. Dessa är kostnadsfria utvärderingsexemplar, men läs licensen själv.
För det andra kan du starta en molninstans hos en cloud computing-leverantör. Jag tänker inte namnge dem, men du vet vilka de är.
När du har operativsystemet Windows igång rekommenderar jag att du installerar MSYS2. (Den första nedladdningslänken ovan från Microsoft har också Visual Studio installerat, om du föredrar det.) Använd en webbläsare (förmodligen Internet Explorer eller vad den nu heter) för att gå till msys2.org, kör installationsprogrammet och på några minuter kommer att ha en komplett MSYS2/MinGW-miljö redo. Följ instruktionerna på webbplatsen msys2.org för att uppdatera pakethanteraren. Öppna sedan ett MinGW (inte MSYS2)-skal från Start-menyn och kör följande för att få de paket som behövs för PostgreSQL-utveckling:
pacman -S git
Nu kan du git-klona förvaret. Medan det går …
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_PREFIXls} make upon flexi
MINGW_PACKAGE_PREFIX är en miljövariabel som är inställd för dig, så skriv in kommandona så. (Det kommer att vara annorlunda för 32-bitars och 64-bitars MinGW.) Paketen utan prefix är MSYS2-paket (dvs. Cygwin). Se del 1 igen om detta är förvirrande. Vid det här laget har du en komplett MinGW-byggmiljö för PostgreSQL. Du kan köra konfigurera, göra, kontrollera och så vidare. Ytterligare paket kan krävas för vissa byggalternativ, men inte alla alternativ fungerar faktiskt; till exempel ingen Readline (använd Cygwin för det).
I nästa del av den här serien kommer jag att titta på alternativ för automatiskt byggande/kontinuerlig integration för Windows som kan användas för att verifiera patchar.