Som PostgreSQL-udvikler har jeg indimellem brug for at få min kode til at fungere på Windows. Da jeg normalt ikke bruger Windows og ikke har en permanent Windows-installation omkring, har dette altid været en smule besværligt. Jeg har udviklet et par teknikker til at gøre dette nemmere, og jeg synes, de er værd at dele. Og faktisk blev denne tekst ret lang, så det bliver en række af flere blogindlæg.
Det første, der er nyttigt at forstå, er de forskellige varianter af Windows-byggemål, og hvordan de er ens og forskellige.
Den, uden tvivl, primære måde at bygge til Windows på, er at bruge Microsoft Visual Studio compiler suite. Dette er, hvad du kunne tænke på som det mest oprindelige miljø. De fleste, hvis ikke alle, binære distributioner af PostgreSQL til Windows bruger denne build. Denne build bruger ikke de normale Unix-makefiler, men et separat build-system under src/tools/msvc/ . Dette parser make-filerne og har noget tilpasset logik og bygger "projekt"-filer, der er specifikke for denne værktøjskæde, som du derefter kan køre for at bygge koden. Lad os kalde dette MSVC build her. Denne build er tilbøjelig til at gå i stykker på to måder:Én, hvis koden faktisk ikke bygger eller kører på Windows, og to, hvis du ændrer noget i det normale (makefiles-baserede) build-system, der får disse ad-hoc scripts til at pause. Så det her er altid meget sjovt at beskæftige sig med.
Den anden måde er at bruge MinGW . Dette bruger GNU værktøjskæden (GCC, GNU binutils, GNU ld osv.) til at bygge indbygget kode på Windows. Du kan tænke på det som "GCC på Windows", men i virkeligheden indeholder det yderligere shim og lim til grænseflade med Windows-systembibliotekerne. Dette bruger det normale Unix-ish build-system ved hjælp af configure og make-filer, men koden den producerer er oprindelig Windows-kode, i princippet svarende til outputtet fra MSVC-builden. Dette betyder også, at hvis koden ikke bygger eller kører med MSVC-builden, vil den heller ikke bygge eller køre her. Men byggesystemet er det samme som for Linux osv., så det bliver sværere at bryde ved et uheld.
Den tredje måde er Cygwin . Cygwin er et undersystem, der præsenterer et POSIX-lignende miljø på Windows. For eksempel tilføjer Cygwin brugere, grupper, fork() , SysV delt hukommelse og andre faciliteter, der ikke findes på oprindelige Windows, men som er standard på f.eks. Linux. Ideen er, at du kan tage kildekode beregnet til Linux eller BSD og bygge den under Cygwin uden ændringer (eller i det mindste med kun ændringer, der ville være inden for det typiske interval for porteringsændringer mellem Unix-lignende systemer). Af denne grund eksisterede en Cygwin-port af PostgreSQL længe før den oprindelige Windows-port, fordi det var en meget mindre indsats. I praksis bryder abstraktionen ned i nogle områder, især i netværkskoden og omkring filnavngivning og -adgang, men generelt går Cygwin-builden meget sjældent i stykker sammenlignet med de andre mål.
Der plejede at være en anden måde at bygge på Windows. Der var win32.mak filer, som du kunne bruge direkte med nmake på Windows, og der var også understøttelse af Borland-kompilere på et tidspunkt. Disse var dybest set stopgab-foranstaltninger til at bygge kun libpq native på Windows, før den fulde native port var ankommet. Disse er nu blevet fjernet.
Der er et andet udtryk, der optræder i denne sammenhæng:MSYS . Grunden til dette er, at MinGW i sig selv ikke ofte er nyttig. Det er bare en kompileringsværktøjskæde. Men for at bygge typisk Unix-software har du brug for yderligere værktøjer såsom bash, make, sed, grep og alle de ting, der typisk bruges fra et konfigureringsscript eller en makefil. Disse værktøjer findes ikke alle som native Windows-porte. Men du kan køre dem oven på Cygwin-undersystemet. Så en måde at bruge MinGW på er inde fra Cygwin. En anden er MSYS, som står for "minimal system", som groft sagt er en skræddersyet delmængde af Cygwin og noget emballage specifikt til at bruge MinGW til at bygge software. Den originale MSYS er nu forladt, så vidt jeg ved, men der er et populært nyt alternativ MSYS2. Mere om dette i et efterfølgende blogindlæg. For nu skal du bare forstå forholdet mellem alle disse forskellige softwarepakker.
Lad os nu overveje, hvordan kildekoden ser disse forskellige byggemiljøer.
En native build, der bruger MSVC eller MinGW, definerer _WIN32 . (Mærkeligt nok er dette tilfældet for både 32-bit og 64-bit builds. En 64-bit build definerer også _WIN64 , men dette bruges sjældent.) PostgreSQL-kildekoden bruger WIN32 i stedet, men det er specifikt for PostgreSQL, ikke gjort af compileren.
MSVC definerer også _MSC_VER til et eller andet versionsnummer. Dette er nogle gange nyttigt til at omgå problemer med en bestemt compilerversion (ofte den slags ting, som Unix bygger plejer at bruge konfigurere til). Bemærk, at MinGW ikke definerer _MSC_VER , så kode skal skrives omhyggeligt for også at håndtere det. Der har været nogle mindre fejl omkring dette, fordi kode som #if _MSC_VER < NNNN for måske at løse et problem med en ældre compiler, ville det også udløses på MinGW, hvilket måske ikke var meningen. (Mere korrekt ville være #if defined(_MSC_VER) && _MSC_VER < NNNN og selvfølgelig ombrydes i #ifdef WIN32 .) MinGW definerer __MINGW32__ og __MINGW64__ , men disse er meget sjældent brugt. MinGW definerer selvfølgelig også __GNUC__ da det er GCC, så kan betinget kode specifik for GCC eller en GCC-version også bruges. Generelt, da MinGW bruger Autoconf, bør disse ting normalt tjekkes i configure i stedet for i koden.
Cygwin definerer __CYGWIN__ . Cygwin definerer ikke _WIN32 , eller WIN32 , og så videre - fordi det ikke anser sig selv for at være native Windows. Det er derfor, at du i nogle kodeområder, hvor Windows kigger gennem Cygwin-abstraktionen, ser en masse kode med #if defined(WIN32) || at håndtere begge sager.
defined(__CYGWIN__)
(Der er nogle støvede hjørner i koden, som ikke altid håndterer alle disse præprocessor-definitioner på en fornuftig og konsistent måde. I nogle tilfælde er dette med vilje, fordi virkeligheden er underlig, i andre tilfælde er det rådden og forkert kode, der skal ryddet op.)
Hvert af disse mål eksisterer i princippet som en 32-bit og en 64-bit variant. En 64-bit Windows-operativsysteminstallation, som er den normale moderne installation, kan køre både 32-bit og 64-bit software, så du kan installere og køre begge varianter på sådan et system. En produktionsinstallation bør sandsynligvis bruge en 64-bit build, og du kan derfor vælge ikke at genere 32-bit miljøet. Faktisk ser Cygwins 32-bit variant ud til at være ret død, og du kan måske slet ikke få den til at virke. Et problem er dog, at 64-bit MinGW har nogle obskure fejl, så når man bruger MinGW, er det nogle gange bedre at bruge 32-bit miljøet, medmindre du vil bekæmpe operativsystem- eller værktøjskædefejl. 32-bit computere er dog åbenbart for det meste på vej ud generelt, så dette er ikke en fremtidssikret mulighed.
Nu er spørgsmålet måske, hvilket af disse miljøer, der er "det bedste". Hvad angår udvikling, betyder det ikke rigtig noget, fordi al kode skal fungere på dem alle. Som jeg nævnte ovenfor, bruges MSVC build til de fleste produktionsinstallationer af Windows. MinGW (eller rettere MSYS2) miljøet er pænere at udvikle sig i, hvis man er vant til et Unix-lignende miljø, men især 64-bit MinGW-miljøet ser ud til at være noget buggy, så det er svært at anbefale dette til produktion. Cygwin kan af nogle anses for at være en historisk kuriosum på dette tidspunkt. Det anbefales ikke at køre en produktionsserver under Cygwin, fordi ydeevnen er ret dårlig. Men Cygwin er faktisk nyttig i nogle situationer. For eksempel virker Readline ikke på nogen af de native Windows-builds, men det gør det på Cygwin, så hvis du er psql-bruger, er det bedre at bruge en Cygwin-build til det. Cygwin er også nyttig i den situation, der er det omvendte af dette blogindlæg:Du er for det meste en Windows-udvikler og vil sikre dig, at din kode for det meste er kompatibel med Unix. Så alle disse tre miljøer har deres værdi og er værd at vedligeholde på nuværende tidspunkt.
I den næste del af denne serie vil jeg diskutere nogle teknikker til at teste kodeændringer på og for Windows, hvis det ikke er dit primære udviklingsmiljø.