Discussion :

[Yuri_Hyuga]

Bonjour,

Je gère actuellement un projet universitaire de 15 personne réalisé en C++.
On utilise beaucoup d'outils externes, et ça nous pose des soucis. J'aurais aimer votre opinion sur la bonne manière de gérer les dépendances dans ce genre de projet.

Quelques caractéristiques du projet :
- Versioning par git
- CMake pour la génération des Makefile/visualstudioproject
- On a des membres sous Win, Mac et Unix (tous en x64)

La problématique :
Une grosse partie de notre projet consiste a ré-utiliser et adapter des outils existants. (On devrait bien avoir 5 ou 6 outils externes à la fin.) D'autre part, pour ne pas re-coder la roue systématiquement, on utilise quelques librairies. (Boost et QT pour l'instant.)

Pourquoi ça pose problème ?

- Les installations qui sont pas les même chez tout le monde (configuration des path, etc)
- Plus c'est long et compliqué à installer, plus c'est pénible pour les membres
- Par là même on ralentit le process de développement

Et aussi, même si c'est moins important pour l'instant :
- L'utilisateur final va devoir procéder à une installation couteuse


Alors, d’après vous, quels sont les bonnes pratiques dans ce genre de cas ? Que font les professionnels ?

Merci par avance pour votre aide/avis sur la question

Yuri

[white_tentacle]

- Les installations qui sont pas les même chez tout le monde (configuration des path, etc)
- Plus c'est long et compliqué à installer, plus c'est pénible pour les membres
- Par là même on ralentit le process de développement

Le premier point est le plus gros problème. Pour diminuer les ennuis, la première chose à faire est que tout le monde utilise la même arborescence.

Ensuite, les chemins utilisés dans les fichiers projets devraient tous être relatifs ou faisant référence à une variable d’environnement (pex, $BASE_PATH_XXX)

Un fichier commité ne devrait jamais contenir la moindre information relative à une spécificité du poste de travail. Certains environnements (pex qtcreator) permettent d’avoir un fichier projet global, et un fichier projet local qui ne contient que les spécificités locales.

Et aussi, même si c'est moins important pour l'instant :
- L'utilisateur final va devoir procéder à une installation couteuse

À toi de lui fournir un programme d’installation qui se charge de cela. Attention à la licence des dépendances, en particulier en terme de redistribution.

[jblecanard]

Salut !

Edit: réponse rédigée avant que white_tentacle ne réponde, d'où la convergence des propos.

Tout d'abord, évacuons la problématique de l'utilisateur final : il doit se voir fournir un installateur complet et adapté à sa plateforme, généré automatiquement par votre toolchain (dans votre cas, ce sera CPack, idéalement). Ce doit en tout cas être bien distincts de l'organisation des dev.

Quand on est en contexte professionnel, la première chose à faire est d'arrêter les numéros de versions des bibliothèques utilisées. Tout le monde doit utiliser les mêmes versions, exactement. Quand la version change, tout le monde doit la changer.

Pour mettre ça en place, il faut fournir aux développeurs une manière simple de télécharger les versions dont ils ont besoin. Là, il y a plusieurs écoles:
- Mettre les libs dans le repo git
- Mettre les libs dans un dépôt de fichier autre accessible par les membres
- Un mix des deux

Ensuite, il faut fournir à l'équipe une procédure d'installation, idéalement une procédure par plateforme. Procédure à fournir dans les sources et dans la doc commune (wiki ou autre chose que vous utilisez), et à tenir à jour. Ca, c'est ton boulot de chef de projet.

Pour l'installation des libs, il faut faire une installation "locale" dans un dossier dédié à cet usage. Ensuite, on peut linker dessus avec des chemins relatifs pour la construction du projet. Cela permet l'installation de plusieurs versions différentes facilement et de se découpler des particularité de la machine hôte.

Ce post peut t'intéresser car il aborde justement quelques problèmes liés au développement en équipe.

[white_tentacle]

Je rajouterai un truc : si tu en as la possibilité, utiliser Pkgconfig permet de bien se simplifier la vie de ce point de vue là aussi.

Malheureusement, il me semble qu’il ne fonctionne pas sous windows.

[Yuri_Hyuga]

Bonjour,

Merci beaucoup pour vous réponses.

Effectivement, le post sur l'arborescence des dépôts m'a bien aidé.

Pour ce qui est des licences, je me suis plongé dedans il y a quelques jours.
La plupart des licences ne posent pas de soucis, mais visiblement, la plus pénible est aussi la plus rependu (GPL & cie). Pour l'instant on s'en sort bien de ce coté là.

Concernant les libs :
On a un dépôt Git avec 1giga de limite max. Je pense que ça sera assez pour mettre les librairies dont a besoin.
A défaut, je les mettrais sur un autre dépôt.

D'autre part, je vais lire à fond la documentation de CMake pour voir comment je peux faire en sorte que les fichiers de sortie (Makefile/.sln) soient configurés correctement en fonction de ça.

J'espère seulement que je vais tout pouvoir automatiser.
(J'ai pas exemple une lib python (bindé vers le C++) qui demande a être lancé une première fois pour qu'elle télécharge la database dont elle a besoin.)

Mais ça me fait déjà bien avancer !
Merci

[Yuri_Hyuga]

Question supplémentaire par rapport à ça :

Une partie de mon équipe travaille sur l'utilisation de CMU Sphinx et son interfaçage avec le reste du projet.

Le problème de Sphinx, c'est que pour le faire fonctionner sur Windows, il a exigé non pas des librairies, mais des dll manquantes. Ca fonctionne quand on rajoute manuellement les dll manquantes dans le système.

Du coup, puis-je ajouter une dll au projet avec CMake, tout comme je linkerais une librairie ?

Note : La DLL manquante semble venir de Visual C++. Devrais-je considérer cela comme faisant partie du minimum d'un environnement standard ?


Merci de votre patience !

Yuri

[white_tentacle]

S’il s’agit d’une dll qui est dans les vc++ redist, il faut juste que tu les ajoutes à ton installateur.

Normalement, elle devrait être installée avec visual pour les postes de développement. Si ce n’est pas le cas, c’est surprenant mais c’est qu’elle doit venir d’un autre composant (comme le DDK par exemple).

Il faut bien que tu sépares la partie compilation de la partie déploiement. Le rôle de ton cmake n’est certainement pas d’installer les dépendances manquantes sur la machine de dev, ni sur la cible. Dans le premier cas, en général, une petite procédure et un référentiel suffisent. Dans le deuxième cas, c’est le rôle de l’installeur.