Nel precedente post del blog, abbiamo discusso delle diverse varianti di build di Windows supportate da PostgreSQL. In questo post, discuteremo di come, come sviluppatore basato su Unix, puoi verificare se la tua patch potrebbe funzionare su Windows. (Per semplicità, dirò "Unix" per indicare Linux, BSD, macOS e simili.)
Innanzitutto, ci sono alcuni modi per controllare la tua patch senza dover avere Windows.
Se la tua patch tocca il sistema di build, ad esempio aggiungendo nuovi file, o più probabilmente aggiungendo condizionali, nuove opzioni di build o logica ad hoc aggiuntiva, potrebbe interrompere gli script di build MSVC, che analizzano i makefile Unix, come abbiamo discusso ultima volta. Ma puoi effettivamente eseguire quegli script anche su Unix. Non c'è (quasi) nulla di specifico per Windows in essi, dal momento che tutto ciò che fanno davvero è analizzare un set di file e produrne un altro. Puoi semplicemente correre
perl src/tools/msvc/mkvcbuild.pl
e guarda cosa succede. Funziona a partire dal commit 73c8596. (Forse salva il tuo lavoro in anticipo, perché ciò potrebbe sovrascrivere alcuni file generati per essere utilizzati dalla tua configurazione locale non Windows). Questo produrrà file di progetto per Visual Studio con cui non puoi fare molto, ma puoi controllare se lo script è stato eseguito, puoi confrontare l'output prima e dopo o se hai apportato "modifiche cieche" a uno qualsiasi dei file in src/tools/msvc/ puoi verificarli in una certa misura.
Un altro modo consiste nell'esercitare le opzioni di compilazione generalmente associate a Windows. Quale di questi è utile dipende da cosa cambia la tua patch. Ad esempio, Windows compila con HAVE_UNIX_SOCKETS non definito, quindi potrebbe essere utile eseguire test manuali se si apportano modifiche al codice di rete. (Ma questo sta scomparendo, dal momento che Windows ora supporta effettivamente i socket di dominio Unix.) Allo stesso modo, HAVE_WORKING_LINK è indefinito su Windows, anche se l'impatto di ciò è piccolo (e sta anche scomparendo; a volte una conseguenza dello scrivere post di blog come questo è scoprire che i problemi che volevi descrivere non dovrebbero essere presenti in primo luogo, e vai a sistemarli). Puoi modificare entrambe queste opzioni modificando src/include/pg_config_manual.h . Un'altra opzione importante è EXEC_BACKEND , che sostituisce il fork() in stile Unix chiama con un fork() più exec() implementazione che può essere mappata su CreateProcess() Su Windows. Questo in realtà si interrompe sorprendentemente raramente, ma se lo fa, puoi eseguire il debug e risolverlo interamente su un sistema Unix. Per abilitare EXEC_BACKEND , puoi modificare src/Makefile.global e aggiungi -DEXEC_BACKEND a CPPFLAGS , o magari aggiungi una definizione a src/include/pg_config_manual.h . (Non sono sicuro del motivo per cui questo è diverso dagli altri; forse un'altra cosa da sistemare a volte. [aggiornamento:anche risolto])
Quando queste opzioni sono esaurite, allora è forse il momento di avviare un vero sistema Windows. Voglio discutere due opzioni che sono facilmente disponibili per lo sviluppatore occasionale. Innanzitutto, puoi scaricare un'immagine Windows demo da Microsoft e importarla in VirtualBox o qualcosa di simile. I link attuali per quello che posso trovare sono:
- https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
- https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
Il secondo di questi è pensato per il test del browser, quindi forse il primo ora è migliore, ma il percorso di test del browser è stato popolare per un po' di tempo. Si tratta di copie di valutazione gratuite, ma per favore leggi tu stesso la licenza.
In secondo luogo, puoi avviare un'istanza cloud presso un provider di cloud computing. Non li nominerò, ma sai chi sono.
Quando hai il sistema operativo Windows in esecuzione, ti consiglio di installare MSYS2. (Il primo link di download sopra da Microsoft ha anche installato Visual Studio, se lo preferisci.) Usa un browser (presumibilmente Internet Explorer o come si chiama ora) per andare su msys2.org, esegui il programma di installazione e in pochi minuti avrà un ambiente MSYS2/MinGW completo pronto. Seguire le istruzioni sul sito Web msys2.org per aggiornare il gestore dei pacchetti. Quindi, apri una shell MinGW (non MSYS2) dal menu Start ed esegui quanto segue per ottenere i pacchetti necessari per lo sviluppo di PostgreSQL:
pacman -S git
Ora puoi git clonare il repository. Mentre corre...
pacman -S ${MINGW_PACKAGE_PREFIX}-gcc ${MINGW_PACKAGE_PREFIX}-gettext ${MINGW_PACKAGE_PREFIX}-icu ${MINGW_PACKAGE_PREFIX}-libxml2 ${MINGW_PACKAGE_PREFIX}-libxslt ${MINGW_PACKAGE_PREFIX}-openssl bison flex make diffutils
MINGW_PACKAGE_PREFIX è una variabile di ambiente impostata per te, quindi digita i comandi in questo modo. (Sarà diverso per MinGW a 32 bit e 64 bit.) I pacchetti senza prefisso sono pacchetti MSYS2 (ovvero Cygwin). Vedere di nuovo la parte 1 se questo è fonte di confusione. A questo punto, avrai un ambiente di compilazione MinGW completo per PostgreSQL. È possibile eseguire configure, make, make check e così via. Potrebbero essere necessari pacchetti aggiuntivi per alcune opzioni di build, ma non tutte le opzioni funzionano effettivamente; per esempio nessun Readline (usa Cygwin per quello).
Nella parte successiva di questa serie, esaminerò le opzioni di compilazione automatica/integrazione continua per Windows che possono essere utilizzate per verificare le patch.
