Discussion :

[jblecanard]

Salut à tous

Je ne commite pas mes binaires non plus, ni tout ce qui peut être régénéré. Si un non développeur à un niveau suffisamment élevé pour utiliser un repo git ou svn, alors il doit aussi être capable de lancer la compile et générer le projet. Dans le cas contraire, on met un dépôt de binaires prêt à sa disposition via un autre canal.

Je me permet de compléter un peu le débat avec un point qui n'a pas été vraiment soulevé : le code multi-plateforme. Je n'utilise pas la technique des macros pour sélectionner le code qui va sur une plateforme ou sur l'autre. Je préfère les mettre dans des .cc (ou .cpp selon votre convention) séparés totalement et laisser l'outil de compilation construire la liste des fichiers à utiliser.

Un .cc mutliplateforme ira dans:
src/[chemin]/fichier.cc

Un .cc qui doit être implémenté différemment ira dans:
src/[platform1]/[chemin]/fichier.cc
src/[platform2]/[chemin]/fichier.cc

[r0d]

J'ai une question à propos de ces arborescences de projets: lorsque vous utilisez des libs externes, comment gérez-vous les versions de ces libs externes (dépendances)?

Prenons pour exemple boost, que tout le monde connait et qui fonctionne bien en tant qu'exemple car elle évolue beaucoup.
La première approche consiste à se fixer une version: je fais mon appli avec la version 1.5.2 de boost, et je reste, jusqu'à la fin, sur cette version. L'avantage est que c'est beaucoup plus simple à gérer. Les désavantages sont multiples, et on les connait.

La meilleure solution, surtout lorsqu'on travaille sur des projets voués à être maintenus et à évoluer pendant des années, est de mettre régulièrement à jour les dépendances. Mais alors, est-ce que vous faites apparaitre la version de la lib ou non? Par exemple, le dossier qui contient les en-têtes de boost s'appelera-t-il "boost-1.5.2" ou "boost"?

[white_tentacle]

En général, les libs externes ne sont pas intégrées au repository. Il y aura exception si la lib est petite, que ça a du sens de la recompiler (par exemple : elle est modifiée par rapport à la version upstream).

Du coup, la question ne se pose pas trop en terme d’organisation projet.

[germinolegrand]

Pour ma part j'ai choisi d'intégrer les lib externes dans un dépôt exprès. J'ai des dépendances entre mes différents dépôts. Je pense que je vais rencontrer des problèmes quand il s'agira de revenir sur un vieux commit (encore que, non, suffit de regarder la date et de revert les différents dépôts à la même date), mais en tout cas c'est plus pratique pour travailler.

[koala01]

En général, les libs externes ne sont pas intégrées au repository. Il y aura exception si la lib est petite, que ça a du sens de la recompiler (par exemple : elle est modifiée par rapport à la version upstream).

Du coup, la question ne se pose pas trop en terme d’organisation projet.

Tout à fait d'accord

J'ai une question à propos de ces arborescences de projets: lorsque vous utilisez des libs externes, comment gérez-vous les versions de ces libs externes (dépendances)?

Prenons pour exemple boost, que tout le monde connait et qui fonctionne bien en tant qu'exemple car elle évolue beaucoup.
La première approche consiste à se fixer une version: je fais mon appli avec la version 1.5.2 de boost, et je reste, jusqu'à la fin, sur cette version. L'avantage est que c'est beaucoup plus simple à gérer. Les désavantages sont multiples, et on les connait.

La meilleure solution, surtout lorsqu'on travaille sur des projets voués à être maintenus et à évoluer pendant des années, est de mettre régulièrement à jour les dépendances. Mais alors, est-ce que vous faites apparaitre la version de la lib ou non? Par exemple, le dossier qui contient les en-têtes de boost s'appelera-t-il "boost-1.5.2" ou "boost"?

Personnellement, je passerais plutôt une (des) variable(s) d'environnement / globales à l'EDI utilisé, #define dans un config.h (par exemple) ou tests dans l'outil de configuration que tu utilises (en fonction des cas ) avec les valeurs adéquates:

Par exemple, des variables comme BOOST_VER_STRING qui prendraient une valeur 1_xy pour tout ce qui a trait au fait de déterminer les noms des bibliothèques et dossiers ou BOOST_VERSION pour tout ce qui permet de déterminer une version minimale à utiliser (outils de configuration automatique, essentiellement)

[r0d]

En général, les libs externes ne sont pas intégrées au repository. Il y aura exception si la lib est petite, que ça a du sens de la recompiler (par exemple : elle est modifiée par rapport à la version upstream).

Ha oui j'avais oublié que beaucoup de gens n'intègrent pas les dépendances externes au dépôt. C'est peut-être même une bonne pratique?

Moi maintenant j'ajoute presque toutes mes dépendances externes à presque tous mes dépôts. Pour deux raisons:
- J'aime bien lorsque, quelque soit l'environnement de dev (un pc vierge par exemple), tu checkout le dépôt, tu compiles, ça marche. Pas besoin d'aller chercher les dépendances à droite et à gauche.
- Si tu récupères un projet vieux de 5 ans (et ça m'arrive assez régulièrement), c'est pas toujours évident (parfois impossible même) de trouver les bonnes versions de certaines libs.

Les inconvénients sont nombreux, mais après 10 ans de pratique, je trouve que ces deux avantages, à eux seuls, pèsent plus que les inconvénients.

[Neckara]

Bonjour,

Personnellement, dès que la lib est petite, je l'intègre au dépôt, c'est plus simple, un seul cmake . && make à faire.

Dès que la lib est assez "importante", je met ses sources et quelques binaires en téléchargement et je donne les URL dans mon fichier INSTALL.