Re: Package creation question
Bonjour
(cc me Je ne suis pas inscrit sur la liste).
Ayant lu les deux articles suivants :
http://blog.flameeyes.eu/2008/11/14/problems-and-mitigation-strategies-for-as-needed
http://udrepper.livejournal.com/19395.html
et après avoir été sollicité par un collègue développeur sur le projet
FreeWRL, j'ai constaté que le paquet dont je m'occupe (freewrl) pouvait
bénéficier de l'option --as-needed de ld.
De plus l'idée était de savoir pourquoi la compilation sous Gentoo avec
cette option échouait.
On a réglé le problème dans le contexte du développement (upstream)
sans toutefois activer l'option par défaut.
Je me suis alors naturellement posé la question : vais-je activer
l'option dans la compilation du paquet (debian/rules) ?
Voici la suite :
Raphael Hertzog <hertzog@debian.org> - Thu, 19 Feb 2009 17:53:19 +0100
>On Thu, 19 Feb 2009, Michel Briand wrote:
>> si je comprends bien c'est d'abord un build normal qui est opéré, et
>> lors de la finalisation alors on peut utiliser --as-needed.
>
>Heu non, c'est un option de ld donc elle s'emploie à la l'édition des
>liens de la phase de compilation.
>
Je voulais dire : c'est une option optionnelle ;)... C'est à dire que
le développeur peut ne pas y prêter attention (build normal). Le
mainteneur peut venir à la rescousse (finalisation) en apportant une
expérience de l'empaquetage et du déploiement. Et proposer alors cette
option (et régler les problèmes quelle génère).
D'ailleurs le premier article souligne que la communication entre
mainteneur et développeur doit être bonne pour que le système de
compilation soit compatible avec l'option (du ressort du développeur).
>> Donc c'est une option du responsable de l'archive et non du mainteneur
>> du paquet, n'est-ce pas ?
>
>Le mainteneur Debian peut toujours rajouter cette option dans les LDFLAGS
>pour l'employer si l'auteur amont ne l'utilise pas.
>
Ma question était donc : doit-on statuer sur son utilisation de façon
générale. Ou est-ce une option à choisir individuellement, par paquet.
>> Le gain évident de l'utilisation de cette option est de ne pas lier le
>> programme à des bibliothèques secondes qui peuvent disparaître ou
>> apparaître suivant les évolution des bibliothèques primaires.
>
>Pas besoin d'aller aussi loin, des paquets employant pkg-config recoivent
>plein de bibliothèques dans les flags de compilation et toutes ne sont pas
>nécessaires, certaines sont optionnels en fonction de l'usage que l'on
>fait et --as-needed permet de ne pas le faire apparaître dans le binaire
>final si elle ne sont pas nécessaires.
>
Tout à fait d'accord. Ceci souligne la pagaille générée par
l'utilisation de pkg-config. Néanmoins, faute de mieux, je l'utilise et
j'en suis globalement satisfait. Si une meilleure méthode s'impose je
l'adopterai volontiers.
>> Cela me semble un gain énorme surtout s'il n'y a pas de contrepartie
>> (effet de bord néfaste)...
>
>Il y a quelques risques/complications mais ils sont maigres de ce que
>j'ai retenu (l'ordre d'appartion des flags -l<lib> sur la ligne de
>commande est notamment important pour le fonctionnement de --as-needed).
>
Remarque très importante à mon avis.
L'utilisation des outils pkg-config, automake et libtool ne remplacera
pas une bonne connaissance d'UNIX.
D'ailleurs ces outils, même s'ils sont particulièrement utiles, sont
très gourmands en temps : on se rend compte à l'usage qu'on passe
facilement 10x plus de temps à mettre au point un système de
compilation auto* plutôt que d'écrire un Makefile unique et bien
structuré comme le suggère, le propose Peter Miller dans cet article :
http://miller.emu.id.au/pmiller/books/rmch/
--
Michel
Reply to: