In de vorige blogpost hebben we het gehad over de verschillende Windows build-varianten die PostgreSQL ondersteunt. In dit bericht bespreken we hoe u als Unix-gebaseerde ontwikkelaar kunt controleren of uw patch mogelijk werkt op Windows. (Voor de eenvoud zeg ik "Unix" in de betekenis van Linux, BSD, macOS en dergelijke.)
Ten eerste zijn er een paar manieren om je patch te controleren zonder dat je Windows nodig hebt.
Als uw patch het buildsysteem raakt, bijvoorbeeld door nieuwe bestanden toe te voegen, of waarschijnlijker door het toevoegen van conditionals, nieuwe build-opties of extra ad-hoclogica, kan het de MSVC-buildscripts breken, die de Unix-makefiles ontleden, zoals we hebben besproken laatste keer. Maar je kunt die scripts ook op Unix uitvoeren. Ze bevatten (bijna) niets specifieks voor Windows, omdat ze eigenlijk alleen maar een set bestanden ontleden en een andere produceren. Je kunt gewoon rennen
perl src/tools/msvc/mkvcbuild.pl
en kijk wat er gebeurt. Dit werkt vanaf commit 73c8596. (Sla uw werk misschien van tevoren op, omdat hierdoor enkele gegenereerde bestanden kunnen worden overschreven die worden gebruikt door uw lokale niet-Windows-configuratie). Dit zal projectbestanden voor Visual Studio produceren waar u niet veel mee kunt doen, maar u kunt controleren of het script überhaupt is uitgevoerd, u kunt de uitvoer voor en na vergelijken, of als u "blinde bewerkingen" hebt gemaakt op een van de bestanden onder src/tools/msvc/ je kunt die tot op zekere hoogte verifiëren.
Een andere manier is om build-opties uit te oefenen die doorgaans worden geassocieerd met Windows. Welke van deze nuttig is, hangt af van wat uw patch verandert. Windows bouwt bijvoorbeeld met HAVE_UNIX_SOCKETS undefined, dus handmatig testen kan de moeite waard zijn als u wijzigingen aanbrengt in de netwerkcode. (Maar dit gaat weg, aangezien Windows nu daadwerkelijk Unix-domein sockets ondersteunt.) Op dezelfde manier, HAVE_WORKING_LINK is niet gedefinieerd op Windows, hoewel de impact daarvan klein is (en het gaat ook weg; soms is een gevolg van het schrijven van blogposts zoals deze dat je ontdekt dat de problemen die je wilde beschrijven er in de eerste plaats niet zouden moeten zijn, en jij gaat ze repareren). U kunt beide opties wijzigen door src/include/pg_config_manual.h te bewerken . Een andere belangrijke optie is EXEC_BACKEND , die de Unix-stijl fork() . vervangt aanroepen met een fork() plus exec() implementatie die kan worden toegewezen aan CreateProcess() op Windows. Dit breekt eigenlijk verrassend zelden, maar als dat het geval is, kun je het volledig op een Unix-systeem debuggen en repareren. EXEC_BACKEND inschakelen , kunt u ofwel src/Makefile.global . bewerken en voeg -DEXEC_BACKEND . toe naar CPPFLAGS , of voeg misschien een definitie toe aan src/include/pg_config_manual.h . (Ik weet niet zeker waarom dit anders is dan de andere; misschien nog iets om ooit op te lossen. [update:ook opgelost])
Wanneer deze opties uitgeput zijn, is het misschien tijd om een echt Windows-systeem op te starten. Ik wil twee opties bespreken die gemakkelijk beschikbaar zijn voor de informele ontwikkelaar. Ten eerste kunt u een demo Windows-afbeelding downloaden van Microsoft en deze importeren in VirtualBox of iets dergelijks. De huidige links daarvoor die ik kan vinden zijn:
- https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
- https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
De tweede hiervan is bedoeld voor browsertests, dus misschien is de eerste nu beter, maar de browsertestroute is al een tijdje populair. Dit zijn gratis evaluatie-exemplaren, maar lees de licentie alstublieft zelf.
Ten tweede kunt u een cloudinstantie starten bij een cloudcomputingprovider. Ik ga ze geen namen noemen, maar je weet wie ze zijn.
Als het Windows-besturingssysteem draait, raad ik aan om MSYS2 te installeren. (Op de eerste downloadlink hierboven van Microsoft is ook Visual Studio geïnstalleerd, als u daar de voorkeur aan geeft.) Gebruik een browser (vermoedelijk Internet Explorer of hoe het nu ook heet) om naar msys2.org te gaan, voer het installatieprogramma uit en binnen een paar minuten kunt u zal een volledige MSYS2/MinGW-omgeving gereed hebben. Volg de instructies op de msys2.org-website om de pakketbeheerder up-to-date te houden. Open vervolgens een MinGW-shell (niet MSYS2) vanuit het menu Start en voer het volgende uit om de pakketten te krijgen die nodig zijn voor PostgreSQL-ontwikkeling:
pacman -S git
Nu kun je de repository git clone. Terwijl dat loopt ...
pacman -S ${MINGW_PACKAGE_PREFIX}-gcc ${MINGW_PACKAGE_PREFIX}-gettext ${MINGW_PACKAGE_PREFIX}-icu ${MINGW_PACKAGE_PREFIX}-libxml2 ${MINGW_PACKAGE_PREFIX}-PACKAGE_PREFIX}-PRxWslt
MINGW_PACKAGE_PREFIX is een omgevingsvariabele die voor u is ingesteld, dus typ de opdrachten zo in. (Het zal anders zijn voor 32-bits en 64-bits MinGW.) De pakketten zonder prefix zijn MSYS2-pakketten (d.w.z. Cygwin). Zie deel 1 nogmaals als dit verwarrend is. Op dit moment heb je een volledige MinGW-bouwomgeving voor PostgreSQL. U kunt configureren, maken, controleren, enzovoort uitvoeren. Voor sommige build-opties zijn mogelijk extra pakketten vereist, maar niet alle opties werken echt; bijvoorbeeld geen Readline (gebruik daarvoor Cygwin).
In het volgende deel van deze serie zal ik kijken naar opties voor automatische build/continue integratie voor Windows die kunnen worden gebruikt om patches te verifiëren.