Bonjour à tous,
il y a quelques mois désormais je proposais à la relecture un package RPM Mingw-cross destiné à l'installation de de la chaîne GNU de compilation croisée GNU/Linux(fedora)-Mingw32.
J'avais conçu ce package de façon avec l'ambition de résoudre les dépendances circulaires entre le triptyque infernal: Mingw - binutils - GCC.
Le package était énorme... c'était ma première tentative de RPM : elle était foireuse comme de bien entendu.
J'ai donc fait table rase et ai repris le problème à zéro.
Pour ce faire, je me suis inspiré de deux sources: premièrement du projet Mingw-cross (
http://sourceforge.net/projects/mingw-cross/) qui procure une version complète de la chaine de compilation et des quelques packages de cross-compilation déjà présents dans Fedora (arm-gp2x-linux-gcc-4.2.2-7, etc...)
Mes objectifs étaient les suivants:
1-je désirais obtenir les quelques packages nécessaires à la cross-génération d'applis GTK+ à destination de windows
2-un des atouts de RPM est la génération automatique des dépendances, je désirais que les dépendances entre ces packages soient gérées correctement
3-je voulais que ces packages fonctionnent avec WINE mais soient aussi aisément "exportables dans un environnement Windows
4-enfin et surtout, je désirais que ces packages respectent la modularité du packaging de Fedora parceque je trouve que, la gestion de dépendances de yum aidant, c'est la seule manière d'obtenir une "relative" maintenabilité des packages.
J'avais effectué un bilan de ma première expérience, mettre Mingw, GCC, les binutils et le couple gmp/mpfr dans un même package n'était pas une solution viable à la long terme, par contre j'avais identifié le besoin de systématiser le bootstrap et gérer les dépendances, ce qui manque cruellement à Mingw-cross.
Au fur et à mesure de mes tentatives j'en suis arrivé à avoir un pool de packages suffisant (de w32api à GTK+), j'ai une solution, élémentaire, pour la gestion des dépendances mais je bute sur des choix qu'il me semble difficile de faire seul.
Premièrement: la gestion des dépendances
Elle est basée sur la redéfinition des scripts find-requires et find-provides de RPM, couplée à un template de fichier spec permettant de les utiliser afin de retrouver: les symboles des DLLs produites, pour find-provides, et référencées pour find-requires.
Deuxièmement: la gestion des packages debuginfo
Comme binutils et GCC qui, en tant qu'outils de compilation croisée, génèrent à la fois des binaires pour le système hôte (Fedora) et d'autres pour le système cible (Windows) certains packages doivent être "strippés" différemment en fonction de leur destination, le but du jeu étant de produire des debuginfo au moins pour les binaires Fedora.
A cet effet j'ai trouvé une solution dans les fichiers specs de la chaîne arm citée plus haut mais cette solution se transpose difficilement: les additions dans le packages sont vraiment très ciblées RedHat et sont qui plus est trop importantes pour être envisagées autrement que comme une mesure d'exception.
Encore une fois des additions aux outils RPM seraient plus génériques
Rien de bien sorcier mais je ne sais pas comment faire coucher ça proprement.
Quelqu'un saurait-il me dire si une système d'extension à RPM est possible?
Troisièmement: la structuration des paquets
Mon idée est la suivante: les fichiers Mingw produits devraient s'installer sur une arborescence séparée qui, par jeu de montage CIFS/NFS-3G, serait réutilisable sur Windows.
Malheureusement, les développeurs de Cygwin/GCC en ont décidé autrement (cf. cygnus tree) ou alors je n'ai pas tout compris.
GCC et binutils ont une fâcheuse tendance à avoir des chemins en dur dans leur configuration, rien qui ne puise se résoudre par patch mais avant de patcher ces deux morceaux là j'aimerais bien savoir si certains d'entre vous ont eu des approches différentes pour traiter ce genre de problème dans des circonstances analogues.
Bref, si quelqu'un avait un retour d'expérience, je suis preneur.
Merci,
A
