Le portage de Linux à Windows de Splash, logiciel de videomapping, en tirant parti de la plateforme MSYS2.
Un peu d’opportunisme
La possibilité de faire fonctionner Splash sous Windows est un sujet de discussion récurrent, depuis le tout début de son développement fin 2013. C’est une des raisons qui ont poussé à favoriser l’utilisation de librairie cross platform pour faciliter cette éventuelle transition, comme par exemple GLFW, FFmpeg et ZMQ.
Un ticket ouvert récemment par un utilisateur (potentiel) a ranimé ce sujet, et ce d’autant plus lorsque qu’un second utilisateur/contributeur, Pip Eicp, a partagé ses propres expérimentations tentant de compiler le logiciel sous Windows. Tout ça a piqué mon intérêt et je me suis lancé dans quelques tests, sachant que j’estimais que le travail pour accomplir cette tâche en semaines.
De la nécessité de bien démarrer
La piste explorée par Pip Eicp constatait à tenter la compilation avec l’environnement de développement MinGW-w64. Pour avoir déjà utilisé cet environnement, et m’être retrouvé bloqué lors de portage d’autres logiciels au fil des années, je n’étais pas très enthousiaste à l’idée de me retrouver dans la même situation. J’ai donc tenté de me lancer très naïvement, en profitant du fait que CMake, le logiciel de construction logicielle utilisé dans Splash, permet de générer des projets pour les outils habituellement trouvés sous Linux, mais également pour XCode (sous macOS) et Visual Studio (sous Windows).
Cela s’est révélé être un échec. À savoir pour commencer que les projets sont utilisables dans Visual Studio, mais a priori pas dans Visual Studio Code, nécessitant l’utilisation d’un outil propriétaire avec une licence limitée. Au delà de ça, les erreurs de compilation se sont révélées difficiles à déchiffrer. J’ai donc mis cette piste de coté, considérant que mon manque d’expérience récente avec Visual Studio allait me mettre de sérieux bâtons dans les roues.
Pour trouver une meilleure voie, j’ai regardé ce qui est utilisé avec d’autres logiciels, à commencer par certains outils que j’utilise régulièrement et qui sont disponibles sous Windows autant que sous Linux. De fil en aiguille je suis tombé sur la documentation pour empaqueter Darktable sous Windows, faisant mention de MSYS2, une plateforme de compilation et de distribution de logiciels pour Windows. Le fait qu’elle repose sur Cygwin, autant que les nombreuses librairies déjà compilées accessibles et l’utilisation d’un gestionnaire de paquets connu, pacman, m’ont intrigué assez rapidement. La possibilité de pouvoir générer un paquet en travaillant dans un environnement proche de mes habitudes n’y était pas pour rien. Cerise sur le gâteau, la génération du paquet à proprement parler se fait à l’aide de NSIS automatiquement à travers CMake, facilitant potentiellement bien la tâche.
Installation de l’environnement de développement
Maintenant que l’orientation globale est donnée, rentrons dans le vif du sujet. Pour commencer, il se trouve que je n’ai pas d’ordinateur fonctionnant sous Windows à portée de main. Je me suis donc naturellement orienté vers l’installation d’une machine virtuelle, en profitant de qemu et de kvm. Sans rentrer dans les détails puisque d’autres l’ont déjà fait, j’ai utilisé une image d’installation de Windows 11 librement accessible auprès de Microsoft. Subtilité importante : il est recommandé de désactiver le réseau de la machine virtuelle durant l’installation, pour passer outre l’obligation de créer un compte Microsoft. Je laisse également de côté le partage d’une carte graphique PCIe avec cette machine virtuelle, sans quoi Splash ne peut pas se lancer. Il y a des guides très bien faits à ce sujet.
Une fois Windows installé et lancé, il s’agit maintenant d’installer l’environnement de développement. Pour la suite je vais considérer le cas précis de Splash, tous les paquets mentionnés ne sont donc évidemment pas obligatoires pour tous les portages de logiciel.
L’installation de MSYS2 se fait très simplement, en téléchargeant le programme d’installation sur leur site web et en l’exécutant. Une fois installé, on peut s’apercevoir que plusieurs “saveurs” de leur environnement de développement. Les spécificités sont expliquées dans leur documentation, je passerai donc dessus. Dans notre cas, j’ai choisi d’utiliser l’environnement UCRT64, qui a l’avantage d’être plus moderne, et supporté nativement depuis Windows 10. Un point important à savoir est que les paquets installés avec une saveur de l’environnement ne sont pas nécessairement accessibles avec une autre, aussi il est important de toujours travailler avec la même saveur.
Une fois l’environnement de développement lancé (c’est à dire, moins prosaïquement, un terminal), nous pouvons installer les dépendances. J’ai pris le parti d’utiliser autant que possible les librairies déjà empaquetées plutôt que de compiler celles fournies en sous-modules, pour limiter les problèmes de compilation.
À partir de là, il s’agit de régler les problèmes de compilation spécifiques à Splash, autant que de désactiver ou remplacer les fonctionnalités spécifiques à Linux. Pour ce qui est de compiler Splash sous Windows, la procédure est détaillée dans la documentation de Splash, je vais donc épargner une redite ici.
Refaire, c’est quand même faire quelque chose
L’historique des commits de Splash est le meilleur endroit pour voir les changements apportés, entre la version 0.10.2 et 0.10.6, pour permettre la compilation sous Windows et régler les problèmes spécifiques. Les principaux soucis étaient liés à des librairies spécifiques au monde Linux et/ou Unix d’une part, au rendu graphique avec OpenGL d’autre part, et enfin à l’empaquetage et au système de fichiers.
Pour ce qui est des librairies spécifiques, il a fallu remplacer la librairie uuid disponible sous Linux par une librairie offrant des fonctionnalités équivalentes, à savoir stduuid. La conversion a été relativement simple.
Il a également fallu revoir l’implémentation de l’utilisation de la librairie ZMQ. Il se trouve que l’implémentation pré-existante utilisait le protocole de transport IPC (inter-process communication), qui n’existe tout simplement pas sous Windows. Il a donc fallu ajouter le support pour cette plateforme des messages in-process. Bien qu’il s’agisse a priori d’un simple changement de chemin dans le code, il se trouve que ce mode de transport est moins permissif pour ce qui est de l’implémentation et qu’il a fallu nettoyer l’ensemble du code faisant usage de ZMQ. Dans l’ensemble, c’est plutôt positif.
Du côté OpenGL, il n’y a pas eu de grosse surprise, si ce n’est un souci de conversion de l’espace de couleur RGB linéaire vers le sRGB. Ce n’est pas la première fois que ça arrive, la précédente étant apparue lors de l’ajout du support d’OpenGL ES. D’où mon étonnement, puisque je pensais que tout était maintenant plutôt carré de ce côté là. De ma compréhension, dans ce contexte spécifique (c’est à dire sous Windows 11, dans une machine virtuelle, en utilisant OpenGL comme API de rendu), le blit d’un framebuffer object vers le backbuffer d’une fenêtre n’applique pas cette conversion d’espace de couleur, alors que c’est le cas dans tous mes tests sous Linux (et qu’a priori c’est ce que disent les spécifications). J’ai donc déplacé la conversion d’espace de couleur pour qu’elle se passe au moment du rendu dans le framebuffer object, ce qui a résolu le problème.
C’est deux points
Reste la question du système de fichiers, qui est géré de manière bien différente sous Windows et … partout ailleurs. Il se trouve que MSYS2 fait déjà une part importante du travail, et rend transparent une bonne partie de la gestion des fichiers. C’est à dire que les chemins Windows sont automatiquement convertis pour prendre un format POSIX, et inversement. La partie qui a nécessité le plus de travail de ce point de vue est l’empaquetage, et notamment la définition des différents chemins d’installation.
La solution actuellement en place consiste à reproduire, à l’échelle des besoins de Splash, une infrastructure de dossier similaire à ce que l’on trouve sous Linux mais circonscrite au répertoire d’installation de Splash. Les quelques spécificités liées à Windows sont lisibles dans le fichier de configuration CMake. Pour le reste, encore une fois CPack associé à NSIS a grandement facilité la génération d’un paquet comptable à partir de Windows 10.
Et c’est tout ?
Au final, l’ensemble de ce portage a pris environ trois jours, en incluant la correction de problèmes mineurs. Bien que Splash n’ait pas été testé dans une installation réelle sous Windows, on peut considérer qu’il est largement utilisable. Comme je l’ai dit en introduction, je m’attendais à un travail beaucoup plus long et douloureux.
La disponibilité d’un environnement de développement résolvant d’emblée nombre de problèmes courants (disponibilité de certaines librairies et système de fichier, entre autres) a été d’un grand secours, autant que le fait de pouvoir compter sur un environnement de développement familier. Et bien sûr, la décision initiale de privilégier des librairies cross platform a été d’un très grand secours.
Il reste maintenant à utiliser Splash en conditions réelles. Et pour ça, en dehors des quelques tests synthétiques que je peux faire, je ne peux que compter sur les utilisateurs pour trouver ce qui casse et m’en faire part. À commencer par tester l’installation !