Posté par diorcety .
En réponse au journal Flatpak.
Évalué à 5.
Clé en main? Non... Ça fait plus de 3 ans que je tourne autour de cette problématique (je suis passé par plusieurs solutions: cross compilation, openembedded, oe-lite, ...) et j'arrive à une solution qui marche bien dans mon cas mais qui demande quand même quelques patchs sur les dépendances pour que ça marche.
Mes contraintes sont: Linux (vieilles distributions < 4 ans) et Windows(avec les outils natifs, donc pas de MINGW, uniquement MSVC), sur une suite logiciel composée de C++ et de python le tout tirant une 30 aine de dépendances(dont notamment libressl, cryptography, paramiko, numpy, boost, pythran, qt et pyside2) et qui doit fonctionner sur tout les CPU 64 bits (donc pas d'autodetection du CPU à la compilation)(ce qui peut est très tricky sous Windows et pour certaine dépendances comme Qt)
Je suis arrivé à faire quelque chose de pas trop mal avec cmake, en utilisant les ExternalProject, et des dépendances avec des systèmes builds fonctionnement aussi bien sous Linux que Windows (pas de autotools donc) et des macros plutôt génériques.
Le soucis c'est surtout la libc. La solution sous linux c'est d'utiliser docker(ou une VM) avec une vieille Centos 5, avec le strict minimum, et tout ce qui est custom (LLVM/Clang récent par exemple) dans les préfixes non standard (pour éviter pendant la compilation qu'une dépendance la trouve et l'utilise). L'image docker manylinux ou dockcross est pas mal pour ça. Sous Windows il suffit de rien n'installer en dépendances(du runtime) ça s'arrête là.
Bien sur il y a quelques patches pour les bugs sur les projets ne gérant pas les prefix custom et autres. Le pire je pense sont les modules python avec une partie native, la détection des dépendances sur Windows étant catastrophique, souvent c'est du bricolage. La palme revenant à lxml dans mon cas, qui va télécharger des binaires pré-compilés sortant de je ne sais pas trop où.
Au final je fais mon superbuild en décrivant simplement mes dépendances et je fais un packaging custom sur la fin: tar.gz pour linux, innosetup pour Windows(la je tire uniquement l'installation de python et du redistribuable MSVC associé), et mes binaires ne sont pas énorme (j'embarque juste tout sauf la libc)
Par contre ça résout pas le problème que tu dois tout surveiller pour les patches de sécurité... Mais au moins tu contrôles de A à Z les binaires produits.
[^] # Re: Espace disque partagé...
Posté par diorcety . En réponse au journal Flatpak. Évalué à 5.
Clé en main? Non... Ça fait plus de 3 ans que je tourne autour de cette problématique (je suis passé par plusieurs solutions: cross compilation, openembedded, oe-lite, ...) et j'arrive à une solution qui marche bien dans mon cas mais qui demande quand même quelques patchs sur les dépendances pour que ça marche.
Mes contraintes sont: Linux (vieilles distributions < 4 ans) et Windows(avec les outils natifs, donc pas de MINGW, uniquement MSVC), sur une suite logiciel composée de C++ et de python le tout tirant une 30 aine de dépendances(dont notamment libressl, cryptography, paramiko, numpy, boost, pythran, qt et pyside2) et qui doit fonctionner sur tout les CPU 64 bits (donc pas d'autodetection du CPU à la compilation)(ce qui peut est très tricky sous Windows et pour certaine dépendances comme Qt)
Je suis arrivé à faire quelque chose de pas trop mal avec cmake, en utilisant les ExternalProject, et des dépendances avec des systèmes builds fonctionnement aussi bien sous Linux que Windows (pas de autotools donc) et des macros plutôt génériques.
Le soucis c'est surtout la libc. La solution sous linux c'est d'utiliser docker(ou une VM) avec une vieille Centos 5, avec le strict minimum, et tout ce qui est custom (LLVM/Clang récent par exemple) dans les préfixes non standard (pour éviter pendant la compilation qu'une dépendance la trouve et l'utilise). L'image docker manylinux ou dockcross est pas mal pour ça. Sous Windows il suffit de rien n'installer en dépendances(du runtime) ça s'arrête là.
Bien sur il y a quelques patches pour les bugs sur les projets ne gérant pas les prefix custom et autres. Le pire je pense sont les modules python avec une partie native, la détection des dépendances sur Windows étant catastrophique, souvent c'est du bricolage. La palme revenant à lxml dans mon cas, qui va télécharger des binaires pré-compilés sortant de je ne sais pas trop où.
Au final je fais mon superbuild en décrivant simplement mes dépendances et je fais un packaging custom sur la fin: tar.gz pour linux, innosetup pour Windows(la je tire uniquement l'installation de python et du redistribuable MSVC associé), et mes binaires ne sont pas énorme (j'embarque juste tout sauf la libc)
Exemple (incomplet):
Par contre ça résout pas le problème que tu dois tout surveiller pour les patches de sécurité... Mais au moins tu contrôles de A à Z les binaires produits.