Discussion :

[sone47]

Bonjour,

Est ce qu'il y a un outil dans boost qui permet de créer uniquement les répertoires include nécessaires aux fichiers include utilisés ?

Par exemple pour la compil d'une lib on utilise b2 --with-XXXX avec le nom de la lib de facon a ne pas tout generer.

De la même manière un script ou autre qui fournit les répertoires d'include nécessaires a une liste de header utilisés.
Par défaut on les a tous ce qui est assez volumineux (ou alors j'ai raté un truc).

Merci d'avance

[Iradrille]

Ya ~80Mo d'includes, c'est vraiment pas énorme.
Si tu veux gagner de l'espace disque, build seulement les libs dont tu te sers, mais encore une fois ya pas énorme à gagner (boost 1.5.0 build en 32 bits, debug + release, yen à pour ~530Mo de libs, donc probablement ~1Go si tu build en 32 et 64 bits).

Ou alors j'ai pas compris la question ?

[Arzar]

Il y a un outil fait pour ça dans boost, qui permet d'extraire uniquement le code source des composants que l'on spécifie ainsi que leur dépendances : boost.bcp

Edit : Bon, après, par expérience, bcp vise large, la dernière fois j'ai essayé d'extraire boost.shared_ptr avec bcp et la moitié de boost est venu avec, j'en ai eu pour 200 headers qqchose comme ça.

[sone47]

OK merci pour vos retours,

Oui c'est ça 100Mo de headers, pas énorme certes mais si je peux avoir uniquement ceux que j'utilise je trouve ça plus clean.
Pour les libs c'est ce que je fais de builder seulement les utilisées.

Je vais regarder bcp

Merci

[Flob90]

Bonjour,

Il y a deux façon de se sévir d'un bibliothèque header only :

• Considérer que c'est une dépendance du projet et fournir au projet de quoi faire référence à cette dépendance. Si l'environnement est clean la seul chose à faire est d'installer (correctement) les dépendances. Et dans ce cas, installer complètement une dépendance évite d'avoir à le refaire pour d'autre projet, ce qui risque d'arriver si tu n'installes que des "bouts".
• L'inclure totalement dans le projet. Dans ce cas se limiter au strict necessaire est envisageable.

C'est dans cette seconde option que s'inscrit boost.bcp, te permettre de fournir dans ton projet qu'un sous-ensemble de boost.

Deux points à souligner sur cette approche AMA :

• Ca permet de ne pas etre dépendant de la version de boost (puisque tu as extrait ce que tu veux), par contre c'est à double tranchant, en effet tu sais que dans les conditions que tu as testé c'est fonctionnel, mais si tes tests sont trop "faible" et qu'un problème est découvert plus tard et est corrigé par une nouvelle version de boost, tu dois refaire l'extraction et l'archive du projet. D'autre part la compatibilité de boost entre les versions est assez forte, si ca marche pour une version, il est trop probable que ca marche pour les autres.
• Tu as en effet gagner de l'espace si tu compares projet + boost à projet + extraction. Sauf qu'à moins de n'avoir qu'un seul projet, garder boost comme simple dépendance permet de ne pas avoir plusieurs fois les mêmes headers de boost dans des projets différents.

Un intérêt de l'extraction est lors du besoin d'éléments proche de boost mais avec une touche maison, dans ce cas extraire et attacher directement les éléments au projet est viable (une autre solution est d'indiquer une dépendance a une version spécifique avec besoin d'un patch pour adapter).

[Klaim]

Juste pour info, les gens de Boost sont en train de mettre en place une solution pour ne recuperer QUE ce que tu veux utiliser (meme si ca fais des dependances dans tous les sens, genre boost::shared_ptr effectivement).
Elle marchera, theoriquement, pour d'autres projets C++ aussi, suivant le modele de pip de Python ou gem de Ruby.

Par contre, ca va pas etre pour tout de suite.