Dans le billet de blog précédent, nous avons discuté des différentes variantes de construction de Windows prises en charge par PostgreSQL. Dans cet article, nous expliquerons comment, en tant que développeur basé sur Unix, vous pouvez vérifier si votre correctif peut fonctionner sous Windows. (Pour plus de simplicité, je dirai "Unix" pour signifier Linux, BSD, macOS et similaires.)
Tout d'abord, il existe plusieurs façons de vérifier votre patch sans avoir à avoir Windows du tout.
Si votre correctif touche le système de construction, par exemple en ajoutant de nouveaux fichiers, ou plus probablement en ajoutant des conditions, de nouvelles options de construction ou une logique ad hoc supplémentaire, il peut casser les scripts de construction MSVC, qui analysent les makefiles Unix, comme nous en avons discuté. dernière fois. Mais vous pouvez également exécuter ces scripts sous Unix. Il n'y a (presque) rien de spécifique à Windows, car tout ce qu'ils font vraiment est d'analyser un ensemble de fichiers et d'en produire un autre. Vous pouvez simplement courir
perl src/tools/msvc/mkvcbuild.pl
et voir ce qui se passe. Cela fonctionne à partir du commit 73c8596. (Enregistrez peut-être votre travail au préalable, car cela pourrait écraser certains fichiers générés qui seront utilisés par votre configuration locale non Windows). Cela produira des fichiers de projet pour Visual Studio avec lesquels vous ne pouvez pas faire grand-chose, mais vous pouvez vérifier si le script a été exécuté, vous pouvez comparer la sortie avant et après, ou si vous avez apporté des "modifications aveugles" à l'un des fichiers sous src/tools/msvc/ vous pouvez les vérifier dans une certaine mesure.
Une autre méthode consiste à utiliser les options de génération généralement associées à Windows. Lequel de ceux-ci est utile dépend de ce que votre patch change. Par exemple, Windows construit avec HAVE_UNIX_SOCKETS undefined, il peut donc être utile de tester manuellement si vous apportez des modifications au code réseau. (Mais cela va disparaître, puisque Windows prend en charge les sockets de domaine Unix maintenant.) De même, HAVE_WORKING_LINK n'est pas défini sur Windows, bien que l'impact de cela soit faible (et il s'en va également ; parfois, une conséquence de l'écriture d'articles de blog comme celui-ci est de découvrir que les problèmes que vous vouliez décrire ne devraient pas être là en premier lieu, et vous allez les réparer). Vous pouvez modifier ces deux options en modifiant src/include/pg_config_manual.h . Une autre option importante est EXEC_BACKEND , qui remplace le style Unix fork() appeler avec un fork() plus exec() implémentation qui peut être mappée à CreateProcess() sur Windows. Cela se casse en fait étonnamment rarement, mais si c'est le cas, vous pouvez le déboguer et le réparer entièrement sur un système Unix. Pour activer EXEC_BACKEND , vous pouvez soit modifier src/Makefile.global et ajoutez -DEXEC_BACKEND à CPPFLAGS , ou peut-être ajouter une définition à src/include/pg_config_manual.h . (Je ne sais pas pourquoi c'est différent des autres ; peut-être une autre chose à corriger un jour. [mise à jour :également corrigée])
Lorsque ces options sont épuisées, il est peut-être temps de lancer un vrai système Windows. Je veux discuter de deux options qui sont facilement disponibles pour le développeur occasionnel. Tout d'abord, vous pouvez télécharger une image Windows de démonstration auprès de Microsoft et l'importer dans VirtualBox ou quelque chose de similaire. Les liens actuels pour cela que je peux trouver sont :
- https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
- https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
Le second d'entre eux est destiné aux tests de navigateur, donc peut-être que le premier est meilleur maintenant, mais la route de test de navigateur est populaire depuis un certain temps. Ce sont des copies d'évaluation gratuites, mais veuillez lire la licence vous-même.
Deuxièmement, vous pouvez lancer une instance cloud chez un fournisseur de cloud computing. Je ne vais pas les nommer, mais vous savez qui ils sont.
Lorsque le système d'exploitation Windows est en cours d'exécution, je vous recommande d'installer MSYS2. (Le premier lien de téléchargement ci-dessus de Microsoft a également installé Visual Studio, si vous préférez.) Utilisez un navigateur (probablement Internet Explorer ou quel que soit son nom actuel) pour accéder à msys2.org, exécutez le programme d'installation et, en quelques minutes, vous aura un environnement MSYS2/MinGW complet prêt. Suivez les instructions sur le site Web msys2.org pour mettre à jour le gestionnaire de paquets. Ensuite, ouvrez un shell MinGW (pas MSYS2) à partir du menu Démarrer et exécutez ce qui suit pour obtenir les packages nécessaires au développement PostgreSQL :
pacman -S git
Vous pouvez maintenant cloner le référentiel avec git. Pendant que ça tourne…
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 est une variable d'environnement qui est définie pour vous, alors tapez les commandes comme ça. (Ce sera différent pour MinGW 32 bits et 64 bits.) Les packages sans préfixe sont des packages MSYS2 (c'est-à-dire Cygwin). Revoyez la partie 1 si cela prête à confusion. À ce stade, vous aurez un environnement de construction MinGW complet pour PostgreSQL. Vous pouvez exécuter configure, make, make check, etc. Des packages supplémentaires peuvent être requis pour certaines options de construction, mais toutes les options ne fonctionnent pas réellement; par exemple pas de Readline (utilisez Cygwin pour cela).
Dans la prochaine partie de cette série, j'examinerai les options de construction automatique/d'intégration continue pour Windows qui peuvent être utilisées pour vérifier les correctifs.
