Als PostgreSQL-ontwikkelaar moet ik af en toe mijn code op Windows laten werken. Omdat ik normaal gesproken geen Windows gebruik en geen permanente Windows-installatie heb, is dit altijd een beetje omslachtig geweest. Ik heb een paar technieken ontwikkeld om dit gemakkelijker te maken, en ik denk dat ze de moeite waard zijn om te delen. En eigenlijk werd deze tekst best lang, dus dit wordt een serie van meerdere blogposts.
Het eerste dat nuttig is om te begrijpen, zijn de verschillende varianten van Windows-builddoelen en hoe ze vergelijkbaar en verschillend zijn.
De, aantoonbaar, primaire manier om voor Windows te bouwen is met behulp van Microsoft Visual Studio compiler suite. Dit is wat je zou kunnen zien als de meest natuurlijke omgeving. De meeste, zo niet alle binaire distributies van PostgreSQL voor Windows gebruiken deze build. Deze build gebruikt niet de normale Unix makefiles maar een apart buildsysteem onder src/tools/msvc/ . Dit parseert de makefiles en heeft wat aangepaste logica en bouwt "project" -bestanden die specifiek zijn voor deze toolketen, die u vervolgens kunt uitvoeren om de code te bouwen. Laten we dit hier de MSVC-build noemen. Deze build kan op twee manieren kapot gaan:ten eerste, als de code niet daadwerkelijk wordt gebouwd of niet op Windows wordt uitgevoerd, en twee, als u iets wijzigt in het normale (op makefiles gebaseerde) buildsysteem dat ervoor zorgt dat die ad-hocscripts pauze. Dit is dus altijd erg leuk om mee om te gaan.
De tweede manier is om MinGW . te gebruiken . Dit gebruikt de GNU-toolchain (GCC, GNU binutils, GNU ld, enz.) om native code op Windows te bouwen. Je kunt het zien als "GCC op Windows", maar in werkelijkheid bevat het extra shim en lijm om te communiceren met de Windows-systeembibliotheken. Dit gebruikt het normale Unix-achtige build-systeem met behulp van configure en makefiles, maar de code die het produceert is native Windows-code, in principe gelijk aan de uitvoer van de MSVC-build. Dit betekent ook dat als code niet wordt gebouwd of uitgevoerd met de MSVC-build, deze ook niet hier wordt gebouwd of uitgevoerd. Maar het bouwsysteem is hetzelfde als voor Linux enz., dus het zal moeilijker zijn om per ongeluk te breken.
De derde manier is Cygwin . Cygwin is een subsysteem dat een POSIX-achtige omgeving op Windows presenteert. Cygwin voegt bijvoorbeeld gebruikers, groepen, fork() . toe , SysV gedeeld geheugen en andere faciliteiten die niet bestaan op native Windows, maar standaard zijn op bijvoorbeeld Linux. Het idee is dat je de broncode die bedoeld is voor Linux of BSD kunt nemen en deze zonder verandering onder Cygwin kunt bouwen (of in ieder geval met alleen veranderingen die binnen het typische bereik van porteringsveranderingen tussen Unix-achtige systemen vallen). Om deze reden bestond er al een Cygwin-poort van PostgreSQL lang voor de native Windows-poort, omdat het een veel kleinere inspanning was. In de praktijk wordt de abstractie op sommige gebieden afgebroken, vooral in de netwerkcode en rond bestandsnaamgeving en -toegang, maar over het algemeen breekt de Cygwin-build zeer zelden in vergelijking met de andere doelen.
Vroeger was er een andere manier om op Windows te bouwen. Er waren win32.mak bestanden die je direct met nmake op Windows kon gebruiken, en op een gegeven moment was er ook ondersteuning voor Borland-compilers. Dit waren in feite noodmaatregelen voor het native bouwen van libpq op Windows voordat de volledige native port was gearriveerd. Deze zijn nu verwijderd.
Er is een andere term die in deze context voorkomt:MSYS . De reden hiervoor is dat MinGW op zich niet vaak nuttig is. Het is gewoon een toolketen voor compilers. Maar om typische Unix-software te bouwen, heb je extra tools nodig zoals bash, make, sed, grep en al die dingen die gewoonlijk worden gebruikt vanuit een configuratiescript of een makefile. Deze tools bestaan niet allemaal als native Windows-poorten. Maar je kunt ze bovenop het Cygwin-subsysteem gebruiken. Dus een manier om MinGW te gebruiken is van binnenuit Cygwin. Een andere is MSYS, wat staat voor "minimaal systeem", wat ruwweg een op maat gemaakte subset van Cygwin is en een verpakking die specifiek is voor het gebruik van MinGW voor het bouwen van software. De originele MSYS is nu verlaten voor zover ik weet, maar er is een populair nieuw alternatief MSYS2. Hierover meer in een volgende blogpost. Begrijp nu alleen de relatie tussen al deze verschillende softwarepakketten.
Laten we nu eens kijken hoe de broncode deze verschillende build-omgevingen ziet.
Een native build met MSVC of MinGW definieert _WIN32 . (Vreemd genoeg is dit het geval voor zowel 32-bits als 64-bits builds. Een 64-bits build definieert ook _WIN64 , maar dit wordt zelden gebruikt.) De PostgreSQL-broncode gebruikt WIN32 in plaats daarvan, maar dat is specifiek voor PostgreSQL, niet gedaan door de compiler.
MSVC definieert ook _MSC_VER naar een versienummer. Dit is soms handig om problemen met een bepaalde compilerversie te omzeilen (vaak het soort dingen waarvoor Unix-builds de neiging hebben om configure te gebruiken). Merk op dat MinGW _MSC_VER niet definieert , dus code moet zorgvuldig worden geschreven om daar ook mee om te gaan. Er zijn hier wat kleine bugs in opgetreden omdat code zoals #if _MSC_VER < NNNN om misschien een probleem met een oudere compiler te omzeilen, zou ook op MinGW worden geactiveerd, wat misschien niet de bedoeling was. (Correcter zou zijn #if defined(_MSC_VER) && _MSC_VER < NNNN en natuurlijk wrap in #ifdef WIN32 .) MinGW definieert __MINGW32__ en __MINGW64__ , maar deze worden zeer zelden gebruikt. MinGW definieert natuurlijk ook __GNUC__ aangezien het GCC is, kan dus ook voorwaardelijke code die specifiek is voor GCC of een GCC-versie worden gebruikt. In het algemeen, aangezien MinGW Autoconf gebruikt, zouden deze dingen normaal gesproken moeten worden gecontroleerd in configure in plaats van in de code.
Cygwin definieert __CYGWIN__ . Cygwin definieert met name niet _WIN32 , of WIN32 , enzovoort - omdat het zichzelf niet als native Windows beschouwt. Daarom zie je in sommige codegebieden waar Windows door de Cygwin-abstractie gluurt veel code met #if defined(WIN32) || om beide zaken af te handelen.
defined(__CYGWIN__)
(Er zijn enkele stoffige hoeken in de code die niet altijd al deze preprocessor-definities op een verstandige en consistente manier verwerken. In sommige gevallen is dit opzettelijk omdat de realiteit raar is, in andere gevallen is het rotte en onjuiste code die moet worden opgeruimd.)
Elk van deze doelen bestaat in principe als een 32-bits en een 64-bits variant. Een 64-bits Windows-besturingssysteeminstallatie, wat de normale moderne installatie is, kan zowel 32-bits als 64-bits software uitvoeren, dus u kunt beide varianten op een dergelijk systeem installeren en uitvoeren. Een productie-installatie zou waarschijnlijk een 64-bits build moeten gebruiken, en dus zou je ervoor kunnen kiezen om je niet bezig te houden met de 32-bits omgeving. In feite lijkt de 32-bits variant van Cygwin behoorlijk dood te zijn, en je kunt het misschien helemaal niet laten werken. Een probleem is echter dat 64-bits MinGW een aantal obscure bugs heeft, dus als je vooral MinGW gebruikt, is het soms beter om de 32-bits omgeving te gebruiken, tenzij je bugs in het besturingssysteem of de toolchain wilt bestrijden. Over het algemeen is 32-bits computergebruik echter duidelijk aan het verdwijnen, dus dit is geen toekomstbestendige optie.
Nu is de vraag misschien welke van deze omgevingen “de beste” is. Wat de ontwikkeling betreft, maakt het niet echt uit, omdat alle code op ze allemaal moet werken. Zoals ik hierboven al zei, wordt de MSVC-build gebruikt voor de meeste productie-implementaties van Windows. De MinGW (of beter gezegd MSYS2) omgeving is prettiger om in te ontwikkelen als je een Unix-achtige omgeving gewend bent, maar vooral de 64-bit MinGW omgeving lijkt wat buggy, dus het is lastig om dit aan te bevelen voor productie. Cygwin kan op dit moment door sommigen als een historische curiositeit worden beschouwd. Het draaien van een productieserver onder Cygwin wordt niet aanbevolen omdat de prestaties behoorlijk slecht zijn. Maar Cygwin is in sommige situaties eigenlijk handig. Readline werkt bijvoorbeeld niet op een van de native Windows-builds, maar wel op Cygwin, dus als u een psql-gebruiker bent, is het beter om daarvoor een Cygwin-build te gebruiken. Cygwin is ook handig in de situatie die het omgekeerde is van deze blogpost:u bent een Windows-ontwikkelaar en wilt ervoor zorgen dat uw code grotendeels compatibel is met Unix. Dus alle drie deze omgevingen hebben hun waarde en zijn op dit moment het onderhouden waard.
In het volgende deel van deze serie zal ik enkele technieken bespreken om codewijzigingen op en voor Windows te testen als dit niet uw primaire ontwikkelomgeving is.