Genezys : humeurs d'un codeur

Gestion des projets

Un projet au sens informatique du terme est souvent l'association de plusieurs projets au sens technique, on aura notamment plusieurs projets pour générer les bibliothèques, et un projet final pour générer l'application.

Cette approche a très bien été mise en place par des logiciels de développement comme Eclipse ou Microsoft Visual Studio. Dans ces 2 logiciels, le développeur ouvre dans un premier temps un environnement de travail (workspace) qui contiendra tous les projets nécessaires à faire fonctionner l'application.

L'intérêt de ce regroupement est de pouvoir tranquillement travailler sur une application dans un seul environnement tout en partageant efficacement le code pour plus de réutilisabilité.

Gestion des dépendances

Lorsque l'on travaille sur un développement important, il est toujours intéressant de pouvoir compiler son projet de la manière la plus rapide possible, afin d'accélérer le processus de Code-Compilation-Debug.

C'est pourquoi les logiciels de développement modernes intègrent une gestion des dépendances entre les différents projets d'un environnement. Eclipse ou Visual Studio permettent de définir quelles bibliothèques seront dépendantes d'autres, afin de garantir une compilation des bibliothèques dans le bon ordre, et de ne recompiler que le nécessaire en cas de modifications dans une des bibliothèques.

Cette approche est bien sûr complètement intuitive puisqu'il suffit pour chaque projet de « cocher » les projets dont il dépend. C'est cette information qui permet de gérer la compilation conditionnelle.

De plus, le fait d'indiquer qu'un projet dépend d'un autre offre une information supplémentaire pour l'édition des liens. L'éditeur de lien est en effet capable de remonter l'arbre de dépendances et de connaitre les bibliothèques à inclure pour la compilation finale de l'application.

Le fait que les projets dépendants se trouve aussi dans l'environnement permet à l'éditeur de liens de connaitre l'emplacement des bibliothèques compilées et d'éviter au développeur de spécifier les chemins des bibliothèques ainsi que leur nom.

Gestion des fichiers

Dans un projet géré à la main, on utilise généralement les Makefiles pour ne pas avoir à recompiler tout le projet en cas de modification. Ce fichier contient en fait les informations de dépendances entre chaque fichier au sein d'un même projet. Le problème est qu'il faut bien souvent créer ces fichiers à la main, alors que le logiciel pourrait gérer cela tout seul.

Je ne parlerais pas ici du cas Eclipse puisque la compilation Java est d'une simplicité enfantine, il suffit juste de recompiler les fichiers .java qui ont changé, rien de bien sorcier pour un logiciel de développement. Par contre, dans le cas d'un projet en C++, l'introduction des fichier d'en-têtes (.h) pose plus de problèmes.

Ces fichiers contiennent en fait des déclarations d'interfaces (fonction, classes, variables). Chaque fichier utilisant au moins une interface doit indiquer au compilateur qu'il souhaite connaître ces déclarations (par un #include). Une inclusion peut se faire dans n'importe quel autre fichier du projet et c'est pour ça que la gestion des dépendances est complexe en C++.

Cependant, Visual Studio a trouvé une solution fort intéressante puisque peu couteuse et extrêmement pratique pour le développeur.

Lorsqu'un fichier de code (.cpp) est modifié, personne d'autre n'en dépend, à part l'éditeur de liens. Le logiciel lance donc la compilation du fichier en question produisant le nouveau fichier objet (.obj) puis lance l'édition des liens pour générer à nouveau l'application.

Lorsqu'un fichier d'en-tête est modifié, il est possible que tous les autres fichiers l'ait inclut. Le logiciel ne prend alors pas de risque et recompile tous les fichiers du projet. Cela peut paraitre lourd mais en pratique, c'est bien moins long que de maintenir soi-même où se trouve inclus les fichiers d'en-têtes.

Une solution parfaite serait d'analyser le code C++ de chaque fichier pour savoir s'il doit être recompilé, cette solution bien plus complexe mais aussi plus efficace semble envisagée pour le prochain Visual Studio mais je ne l'ai pas encore testé.

AJOUT: Hadrien me fait remarquer que la compilation est parfois plus optimisée que ce que j'annonce, tests à l'appui. Apparemment donc, Visual Studio 6 intègre déjà une gestion plus fine des dépendances que ce que j'énonce.

Et si on mixe le tout ?

C'est là que ça devient vraiment intéressant. Si vous modifier un fichier de code d'une bibliothèque dont dépend une autre bibliothèque dont dépend votre application, la compilation se fera alors comme cela :

• compilation du fichier ;
• génération de la 1re bibliothèque puisqu'au moins un fichier a changé ;
• génération de la 2e bibliothèque puisqu'une bibliothèque dont elle dépend a changé ;
• éditions des liens et construction de l'application finale.

Tout cela en une seule fois, c'est-à-dire en demandant la compilation de l'environnement.

Voilà, vous avez mon opinion

Bien que j'assume entièrement les propos que j'ai tenu dans mon précédent billet, je ressentais le besoin de vous faire partager ces quelques idées qui m'ont conduit à l'écriture de ce coup de gueule.

Certains diront que je suis pro-Microsoft, je n'ai pas de réponses à leur faire, qu'ils continuent de croire ce qu'ils veulent.

D'autres diront peut-être que je chipote sur de petites choses, mais j'ai remarqué que la puissance d'un outil se mesurait souvent dans les premières secondes d'utilisation. Mais lorsqu'il s'agit d'un outil de développement et qu'on connait le cout de démarrage d'un projet, on se dit que de petites futilités comme celle là font finalement gagner énormément de temps.